Running a Project
This section is an in depth guide for newer Invoites and a great reference for those who run projects often. Projects come in all shapes and sizes, but these basics can help you stay organized and keep perspective.
Begins with a signed Statement of Work (SoW) from the client, prepared by Jon.
If you haven’t been a part of the sales process for the project then review the SoW and discuss the project with the Sales team to understand the background of the project and client. All SOWs for projects can be found on Dropbox, or ask Jon for the latest.
Spend 2 hours doing the following research to understand the industry, business, and team:
- Read the client’s website
- Read the key stakeholders LinkedIn profiles
- Read the client’s wikipedia page
- Read the latest news on the client and their product(s)
- Find any competitors and understand what they do differently
- Create an email listserv for the Invo team working on the project. Format should follow email@example.com. An example is firstname.lastname@example.org. Setup listserv with Google Groups. An admin of the Google Business account will need to set this up. Just ask if you need help.
- Add project to StaffPlan. Check if the project already exists in StaffPlan, sometimes we’ll do pre-planning of staff prior to a signed Statement of Work (SoW). Add all team members for the project and their planned hours for the duration of the project. If the client does not exist, then add the client.
- Setup Slack channel for the project. Channel name should follow proj-clientname. An example is proj-dataxu.
- Setup Dropbox for internal team in Invo Projects using the following structure. Dropbox example.
/Invo_Projects /ClientName /client /background /research /design /deliverables /production /images /research
For multiple projects for a single client, add projects as directories within Client directory.
/Invo_Projects /ClientName /Project1 /client /design /Project2 /client /design
Two Weeks before Kickoff
- Identify POC (point of contact(s)) with client. While we encourage communicating with all on the project, this person will be your main contact on the client team to help with logistics.
- Schedule kickoff date(s), times, and location with the client.
- Craft the kickoff agenda. View Kickoff Template Google doc for help.
- Send client and stakeholders the Kickoff Survey and ask them to complete within 2 days. Make sure you’re sending this enough in advance where we’ll have time to review the responses prior to kickoff. Below is an email template to send to the client. At this point, you may not know all the stakeholders, so sending to the client lead and asking to distribute to their team is fine.
Subject: Project Prep
I'm <yourName>, lead designer on this project, and we’re looking forward to working with you over the next few months. We are looking to have our kickoff on <suggestedDate/TimeInfo>. Let us know what days/times work best for you, and we'll plan around those.
As we put together the schedule for the kickoff, we’d like to hear each person’s perspective on the project so we can refine that into a single message during the kickoff. Could you and you and your team individually fill out this 7-minute survey by <insertDeadline2businessDaysIdeal>?
One Week before Kickoff
- Create Basecamp project. Project name should follow ClientName: ProjectName (ex. DataXu: Forecasting). An admin of Basecamp will need to set this up. Just ask if you need help
- Request any preliminary materials from the client they think will help prepare for the project, and request client product, software, or VPN access as early as possible when applicable.
Get familiar with handling invoicing for the project.
- Read SoW terms for payment (# of invoices, dollar amount per invoice, when to send, payment net terms)
- Request billing contact information from client
- Identify dates for sending invoices and receiving payment. Let sales team know of those dates to update the financial forecast.
- Be sure to track your time on Staffplan. Check to see if billing is standard, by the hour, or by the hour + type of work. You may need to track your hours more specifically.
- Create invoice (workflow to be documented) and send to client billing contact on the pre-determined date.
- Add invoice to the Dropbox folder
Invo_Projects > all_invoices > clientNamefor our records. See the Invoice Directory Structure section in File Management for more info.
- Follow up when a payment becomes late:
Subject: Invoice #<invoiceNumber> Involution Studios / We Create Goodness LLCs
Please see attached Invoice #<invoiceNumber> in the amount of $<invoiceAmount> for <nameOfService - example design consulting> on the <nameOfProject> Project. This is the <currentNumberInvoice> of <totalNumberOfInvoices> invoices you will receive for this project. Payment terms are net 30 days upon receipt of this invoice. Please make checks payable to our parent company, We Create Goodness LLC, EIN #<insertEINNumber>.
- Review Statement of Work
- Create project schedule, including regular meetings and weekly deliverables. Share with all stakeholders on Basecamp
- Create project spec 1-pager document. Example to be created.
- Send message to client about communication channel. If we’re using multiple lists, Slack, or Basecamp, then outline that in the message.
Subject: Project Comm Channel Team,
Message: We've put together an email list for contacting the Invo team, <clientName>-email@example.com
People on this list are: <invoNames>
Please use this list to keep the Invo team in sync.
- Send kickoff notes to client within 24 hours. This can be posted on Basecamp.
- Send schedule of deliverables to client within 24 hours. This can be posted on Basecamp.
Subject: Schedule v01Team,
Message: Attached is the schedule for the project.Our weekly rhythm for reviewing the latest deliverables is: <day>, <timeWindow> @ <location>. Our first meeting will be <date>.
- Invite all stakeholders to Basecamp project. Add Invoites to Our Team and client team to The Client.
- Identify appropriate billing contact and send out first invoice.
Meet once a week. Face to face is preferred. For remote meetings, use your preferred communication channel: GoToMeeting, Google Hangout, Skype, Phone. Duration: 1 to 1.5 hours. Adjust as needed.
Post deliverables on Basecamp 2 hours prior to meeting or the night before. Some clients review the deliverables in advance and come to the meeting ready with feedback. Others use the scheduled time during the meeting to review the latest deliverables. Adjust as needed. Message structure on Basecamp for deliverables:
Subject: Deliverable name, version number, and current project week with total weeks (ex. 'Create Campaign v04 :: Week 5 of 10').
Message: (Describe what’s new in the deliverables, what you’d like to discuss in the meeting, and your next steps as you currently know them.)
If meeting face to face, then print the deliverables using the large format printer and bring to the meeting. Printed deliverables are helpful for everyone to circle around, discuss, and mark up with feedback. Often, clients will hang these posters in their office for the entire company to have visibility into the design, see progression, and mark up as well.
Meeting Agenda Template
- First 5 minutes: Overview of what you’ll be reviewing and what you’d like to get out of the meeting.
- Next 50 minutes: Review designs, receive feedback, ask questions.
- Last 5 minutes: Summarize what you heard during the meeting and what you’ll be working on for next week.
Immediately document your notes and post to Basecamp after the meeting. Message structure on Basecamp:
Subject: Meeting Notes, date of meeting, and current project week with total weeks (ex. 'Meeting Notes, 27.Oct.14 :: Week 8 of 10').
Message: (Document the feedback, any changes in direction or schedule, and re-iterate what you’ll be working on for next week.)
Take photos of the team and client engaged a few times throughout the project. These will be used to document the project and possibly for marketing.
Done by the project lead
For each quarter of the project completed, especially at the end of the meeting do the following with the client:
- Provide a high-level of the project status; how we’re doing against the schedule, what we need help with, and if necessary, make any adjustments so we can realistically deliver on time.
- Request stakeholders to critique how Invo is doing, what can be done better.
Filenames, especially those we will deliver and share with the client should follow a consistent structure, such as clientnameprojectnamedeliverablev01, ie. jnjicbcareplanflow_v01.pdf.
At the bottom of every document, include the client name, project name, deliverable name, version number, Invo team names (alpha order of last name), date (format 19.Feb.15 which InDesign automates for you using the documents last modified date), and GoInvo logo.
Numbering and Naming Screens
If there are multiple screens or ideas within a page then each screen or idea should be numbered and named appropriately. Numbering helps people identify which comp to look or are referencing on the page. Naming helps people understand what that comp is generally about.
It’s helpful to annotate your documents so others can understand the details behind the images and to guide people through the workflow.
This Adobe InDesign template includes the styles (paragraph + object styles) to mark up deliverables: labels, annotations, and branding. Download InDesign Template
Look to Project MGMT Resources for more.
- Project Proposal - Project proposals are sent to a potential client we’re in discussions to work with. The proposal provides background on the company, the team, what the design process and schedule could look like for the project, and cost. The proposal starts the conversation to refine the engagement and ultimately create a Statement of Work (SoW).
- Statement of Work (SoW) - The Statement of Work outlines our engagement with the client. It describes what the project is about, the weekly schedule, deliverables, team size, and cost. To begin the project, the client will need to agree to and sign the SoW. Doc Example 1
- Schedule - Every project has a schedule and should be roughly based on the Statement of Work: goals and duration. During the kickoff, the schedule should be finely detailed with the client. It should state clearly what is delivered each week until the end of the project. For longer projects, it could be helpful to make a long term schedule that can be flexible, and a more detailed schedule covering the next few weeks or months. PDF Example 1
- Project + Product Spec - Describes the project and product in a short 1-2 pager. This document has 3 main sections: Vision, Background, Goals. Each section has a specific description for the project and product. First draft is created based on the client kickoff survey responses. During the kickoff we’ll use that draft as a conversation starter to flesh out a v01 that all stakeholders agree to. This guides our purpose throughout the project. This is subject to evolve over time, so this document may need to be revised. PDF Example 1
- Product Questions - PDF Example 1
- Competitor Research - Research companies or products doing similar things in the client’s space
- User Research - One-on-one sessions with target audience to establish baseline mental models on current use and pain points
- User Research Report - Summarizes user research conducted for this project, describing methodology, schedule, and profiles of user roles interviewed/surveyed.
- Needs Map - Describes and explores needs from the user perspective, making considerations outside the product and process to better understand the full scope of the user’s state of being. PDF Example
- Journey Map - Describes the path a user may take through the service or product, highlighting thoughts or feelings informed by user research. PDF Example
- Sketches - Sometimes we’ll share our sketches if we’re looking for quick feedback and have not yet started to digitally create the concepts. PDF Example
- Pixel Perfect Comps - Exact perfection in UI details. These comps will provide guidance and the assets for a UI Engineer to align the software with. Whenever sending design files to others, make sure artboards, layers, and groups are appropriately named and organized. PSD Example | XD Example | Sketch Example
- Presentations - At times, we create specific presentations tailored to the clients needs. Sometimes we present to key project stakeholders, clients customers, or the entire company. PDF Example | Keynote
- Process Map - Maps out the process of the service. This could map out all parts of the process, even if we’re not designing it, because we should know the entire lifecycle of a person using the service. PDF Example 1
- Product Ecosystem - Inventory of all the clients products plus their relationships and overlaps between products. PDF Example 1
- Product Blueprint - Inventory of a product’s features and functions PDF Example 1
- Prototype - A demo of part(s) of the software we’re designing. Highly iterative. Each prototype should have a clear intention to test. Prototype formats can vary based on project needs but can be: Keynote, Invision, XD, Framer, Flinto, Proto.io, HTML, native... etc.
- Production Code - Using our designs, we’ll work with the client to develop the new software. See [link to Product Engineering section] for more information.
- System Diagram - High-level architecting of the main components of the service, relationships, and actions. PDF Example 1
- UI Workflows - Many of our deliverables are UI Workflows. These show the screens, how people will use the software through a series of screens, and any details to describe the experience. PDF Example
For Design Projects:
- Final design files (PSD, XD, Sketch, Indd) - Layers should be clearly grouped and labeled
- Final designs as PDF or presentation for the client to review and socialize among stakeholders
- Final PNG files - Fullsize (or 2x), lossless PNGs as zip, organized by workflow (or otherwise understandable)
- Final icon library as svg (optional, but nice handoff to engineering)
- Design Spec - Details key design patterns, as PDF style guide, CSS, LESS, or SASS. PDF Example | CSS Example
- All weekly deliverables - While the client should already have these, it is helpful for them to have them in one place (On Basecamp or separate and shared Dropbox folder)
- All reports prepared during the project
- Implementation Analysis - Details an estimated effort to build the design we’re working on. Includes amount + type of people, time, and releases. Typically created towards the end of the project where we’ll have a good sense of the product. This exercise takes about 2-3 days internally and then we’ll review with the client and their engineering team. It’s expected to have a revision or two based on feedback. PDF Example 1 | Keynote
- Project Assessment - Review internally and with client how the project went. Review Invo’s performance, and client’s performance from Invo perspective and client perspective. As part of this, send out project evaluation survey. See below, as part of Wrap-Up.
For Projects involving Code:
- All source code developed
- The final executables (if applicable)
- Instructions on how to deploy and build the application/code
- List of dependencies.
- Source code should be well documented.
- For production applications, it is helpful to include a directory structure outline.
- See [link to Product Engineering section] for more information.
Before the End
At 75% Completion of the Project
Identify the completion date of the project
- Take into account weeks that Invo did not work on the project due to holidays or vacation and any under/overburn.
- It is useful to plan a few days of wrap-up after the final client meeting. Realistically there will be a few last minute changes the client requests.
Prepare a list of final deliverables, previously agreed upon with client, which should include:
- What Invo expects to complete by the end of the engagement
- What Invo expects to have partially complete at the end of the engagement
- What Invo expects to not have worked on at the end of the engagement
During a regular meeting, reserve 15 minutes to discuss this list with the client. Get their feedback on the priority.
After discussing in person, send out an email summarizing that information. Below is an example.
As we discussed today during our meeting, this project will be finishing on Friday, December 18. We will have our final meeting on December 16. Based on the feedback from today's meeting, here is how we will focus during this last 4 weeks.
Task 1 discussed at meeting
Task 2 discussed at meeting
Task 3 discussed at meeting.
Please let us know if you have any questions.
One Week Before the Project is Complete
- Work out any final logistics of giving the clients the final deliverables.
Communicate the types of deliverables to the client
- This will allow them to ask any questions about these files.
- Below is an example e-mail outlining the types of files.
We will be posting the final deliverables next Wednesday, and we are available for a wrap-up meeting next week Monday, Tuesday (except 2-3), or Wednesday.As we have discussed, for the final deliverables, we will be providing:
- Style and functional guidelines in context of the component breakdownreviewer and submitter workflows
- Final pngs and a link to final PSDs (most likely to large to post)
- Prototype code for the with 3 scenarios we outlinedLet us know your availability for a wrap-up meeting next week.
On the Final Day of the Project
- Deliver all deliverables to the client. Include with these a description of all the deliverables and any notes about them.
- Here is an example e-mail outlining this information:
Our engagement with ACME ended last week. This week we were finishing up a Web Based User Interface Design Guide for ACME. The design guide is made up of 3 sections – Principles, Process and Examples. To close out our engagement, we have included all the final deliverables in a dropbox folder that includes the following:
- Prototypes: The code for the prototypes we developed during the engagement.
- Web Design Guide: The HTML and CSS for the design guide we prepared.
- User Research Report: including all of our findings from the user research.
- Product Ecosystem diagram
- Screen designs which we have delivered throughout the engagementThanks and we look forward to working with you again. Web-based User Interface Design Guide can be found at: http://code.goinvo.com/acme/guide/ Final Deliverables Dropbox folder: https://www.dropbox.com/sh/ptcanvw9dzz8164/croWcj9h5N
Tasks for the Team
Within 1 Business Day of Project Completion
- Entire team completes Invo Exit Survey.
- Entire team pulls together a handful of the best designs, sketches, and photos to be used for marketing materials. Place logically named images in dropbox > Graphics > Portfolio > <clientName>.
Tasks for the Lead
- Within 1 Business Day of Project Completion send final invoice for the project to the client’s billing department. See invoicing above.
- Within 2 Business Days of Project Completion send each person from the client team the Client Exit Survey. Here is an email template to individually send to each person from the client team. Optional: Make the message more personal by acknowledging the contribution that person added to the project.
We wanted to thank you again for a great project. We enjoyed working with you. If there's anything else you need help with in the future, let us know!
So that we can continue to provide really great work and service, we'd like to get your honest feedback on how Invo did for the project.
Can you fill out this 5 minute survey by tomorrow? http://goo.gl/forms/jge3n36Lh1
Within 3 Business Days of Project Completion, complete Marketing Material Survey.
Send out a Summary of the Project to firstname.lastname@example.org. Now that the project is complete, take a few minutes to summarize what work Invo did during the project. Summarize it in an e-mail to the full studio.
Today we are wrapping up our latest gig with ACME Corporation.
Reshma, Eric and I started working with ACME at the start of February and we've had 2-3 people working on research, design, prototyping, and production code for most of the time since then.
In the first part of the engagement, Eric led an effort to help ACME re-envision the future of their platform and identify an approach for a scheduled rollout which will take place over the next 2-3 years. To help validate the design and sell the new vision internally and externally, Ivan and I built a series of prototypes which they are still using today to sell their future to important customers.
Danny and Michael began work on in July on the first set of production code. In addition to executing on the design vision, they have worked with ACME to define the next technology stack(Angular as a client side MVC separated from their API server) that will be used on all their future UI development. They did a good job of involving the UI dev team in the large architectural decisions. Despite the project being understaffed from ACME's side, Michael and Danny were able to deliver a top-notch experience.
Feedback on the new screen from some of ACME's bigger customers has been very positive thus far and the Product team is very excited about what this new screen will provide. Additionally the team we have been working with have universally echoed the sentiment that this project has been one of the smoothest that they have worked on.
Here are links to a few videos of the app on the demo environment. I have also attached some screenshots of the before and after.(Link 1)(Link 2)
Congrats to all that have been involved with ACME over the last 8 months.
- 3 to 6 Months After the Project is Complete, if it makes sense, consider reaching out to the client 3 to 6 months after the project has ended. Ask them how things are going and get some feedback about the work (after they have had more time to really digest and stress test the work we’ve done).