Phase Zero: New Business¶
A lead comes in through phone, email, or referral.
New biz team sets up an investigatory call with the prospect to see if we’d make a good fit. New biz can determine if the project seems viable, if the client will be fun to work with and may have funds set aside for the project. The team acts as gatekeepers to vet leads as they come in.
YES New biz team high fives, debriefs, and sets up call for teams.
NOT US If things look good but for some reason we can’t take the lead, we send a polite “would love to work with you but the timing isn’t right” email. If there’s a shop we think could help the prospect we provide contact information for the prospect to initiate contact.
NO THANKS If things don’t look good (red flags, ridiculous budget, or nonexistent timeline), a “thanks but no thanks” email is sent to the lead.
If the new biz team feels good about the lead, they send out an email to the team about it: who the prospect is, what they need, and any other important info gleaned during the screening call. When working on a large lead, a start-up, or a completely undefined lead, sometimes it’s impossible to determine who should be on the team right off the bat since roles have yet to be defined. The lead is sent out to both the core team and our Friengeneers with the understanding that the core team has first dibs on new projects coming in the shop. It’s a good idea to welcome teammates fitting anticipated roles that are likely needed, and then re-evaluate these roles together throughout the project. It’s also a good idea to assign project managers for projects early on, so one person can keep a high-level view of the project and do the communicating on the team’s behalf. The goal is to vet the lead to make sure it is a good fit for nGen.
nGeneers have two days to respond to the email. Responding means they dig the lead or want more info before committing. Responding with a thumbs up also means they’d probably like to work on the project, although they don’t have to. If no interest from specific needed roles is expressed, others can stand in for a call and relay info back while the team looks for someone to fill the role. If there are not enough nGeneers to fill all the roles the project might require, we invite Friendgeneers to work with us on the project.
If, after two days, nGeneers express that the lead doesn’t feel good, we send a “thanks, but no thanks” email to the prospect.
A conference call with the prospect is scheduled. The project manager leads the call and helps guide questions to determine the needs, goals, and complexity of the project and notes how the client interacts with the team. Team members can introduce themselves and assess the prospective client and project, asking any additional questions. It’s important for the team to go into the call prepared; with their relevant questions based on the known project information in the project manager’s hands so he or she can lead the call.
It’s a good idea to assign one note taker for consistency and, whenever possible, record the call.
A debrief follows right after the call. If all things shout “go”, the new biz team works with the project manager and the team to determine a team champion—the team member who will take the lead role for design and/or development—to set up next steps.
If the lead reeks of red flags, new biz sends a “thanks but no thanks” email.
Getting a solid handle on the scope of a project involves a couple of steps. The project manager works with the rest of the team to analyze the scope of the project. Any roles that are in need of a team member can be analyzed and filled from a list of Friendgeneers.
We have started estimating time in weeks, not hours. This way, we can determine our team availability according to the percentage of time not already allocated to other projects. So for example, if we know a team member needs to devote 30% of the week to one project and 30% to another, we say they are 30% available that week for additional work. Our teammate can estimate how many weeks their portion of work might take if they only have 30% of each week available to a particular set of tasks. From there, we get every project teammate’s availability and their estimate on the number of weeks they need to finish the project including time for approvals and turnarounds. Estimating in weeks instead of hours gives us a fairly accurate idea of the total number of weeks a project should take and gives us the flexibility to adjust this timeframe if client approvals or deliverables come in late. It also prevents us from over scheduling team members and helps us maintain a high-level view of our overall availability.
We’re working hard to reduce the number of projects our teammates are working on at any given time so that they can stay productive without being spread thin across too many tasks. Our ultimate goal is to reduce the number of projects each team member has on their plate to no more than three (two billable, and one internal). We’re also very excited about our team-creation project called Jellyfish Jobs which should be ready soon. It will let us form virtual teams with core members and Friendgeneers when new projects come in and let us track how many active projects each teammate has at any given time.
Timelines on a project always change. Sometimes, through no fault of their own, a client will need more time to get approvals or other deliverables ready for our team. An important thing to note is that with weekly estimating, when our clients take longer than anticipated to complete tasks, we add additional weeks to the budget to accommodate the delays. Because this time can add up quickly and blow the budget, we protect our clients and ourselves with a “Pause Clause” in our proposal which says that we can put the project on hold and reschedule it according to our availability if deliverables are two weeks late. That way, no work is done on the project (aka no budget is used up during the pause) and the client now has some time to complete approvals or upload assets and deliverables.
If we’ve underestimated the number of weeks it will take to finish the project, we re-estimate internally as soon as we’re aware, and let the client know right away. Over-communicating is always better than under-communicating. If you’re thinking of trying weeks instead of hours, try estimating both ways and compare. If the numbers are wildly off, it might be time to adjust how you are billing or how accurately you are estimating time. Another way to strengthen your estimating is to have other team members weigh in on the estimate. That way newer teammates or people who are not as confident with estimating have supports in place to help them be more accurate. At the end of the day, we don’t feel comfortable telling our teammates how much time they should take to do a task. They need to be the ones to share that with the team because we all trust we’re doing our best work and we want to help keep each other accountable.
A separate discovery can really help you out here. Although a final budget may not be clear until after separate discovery, determining a rough ballpark of your budget is important to both parties, especially since these numbers almost always evolve. It will help everyone know if it’s feasible for the project to proceed.
If we aren’t doing a discovery phase, we gather all the information we can to determine the estimated timeframe and budget. This includes things such as:
- overall project and business goals
- obstacles and bright spots
- stakeholder info (how many, what type of involvement, availability)
- content types
- current and desired technologies and functionality
- is this an app or site; which platform
- any anticipated external/third-party needs (DNS, hosting, email, integrations, newsletter vendors)
- if the project is required to work in outdated browsers
- extraneous concerns (marketing, branding, phases, business strategy)
- required components
More than one stakeholder? Increase the scope. Tight timeline? Increase that scope! Multiple integrations or an in-house staff? You got it. For every layer of complexity, it’s best to increase the scope with extra time.
Andy Rutledge created a good resource for defining scope, although it calculates hours not weeks. Consider using it as a guide to defining the size, projected timeline, and cost of your project.
Once we have an idea of all the bits and pieces, we have every teammate estimate how many weeks should go into his or her portion. That way, rather than simply breaking the scope into phases, we have a solid idea of all the components and how they fit together. Once this has been done, we can allocate time to phases for things like asset collection, content writing and approvals, and holidays or vacation if needed.
The team works with the biz dev team to create a short proposal. The proposal should highlight who will be on the team, the expected scope, budget, and timeline. Ask nGeneers not on the team to review what you’ll send and how it will be formatted.
Now that the proposal is ready, the team packages it with a Terms Of Service agreement and presents it to the prospect. These two documents seal the deal. Then you await approval. Have the prospect sign and date both, and return copies of each.
WAIT! SIGN-OFF REQUIRED!
Numerous requests for revisions to your proposal can be a red flag that indicates the client wants to drive. Don’t get sucked in to more than one or two revisions unless they’re warranted!
Once both documents are signed and received it’s time to initiate a deposit invoice and the prospect officially becomes a client. Lori asks the client for contact info for each person on their side then sets up the project in Basecamp and Harvest, sends a deposit invoice, imports any past communication—including the signed documents—and we’re off! (Well, once the deposit payment is received, that is.)