The planning phase
Before the project kicks off, it's important to create a complete plan to limit scope creep, misunderstandings, and client and team frustration. This planning process is our discovery phase, and it's billable work.
When a client requests work from us, we have two options in how to treat it depending on the scope:
- Individual features or small requests are best-handled in the default "General Requests" list at the top of a space
- When the scope is on the scale of months of work or hundreds of hours, it probably makes sense to set up as a dedicated project.
🎯 Setting delivery goals
Delivery goals are our starting point for featureset, timeline, and budget.
Sometimes there are unknowable unknowns or other unexpected factors that shift these goals over the course of a project, but we should have a clear starting point that's been clearly communicated to the client before kicking off work.
Defining required functionality
This defines what we'll deliver. Sometimes, plans are made with future functionality in mind as well, and these future goals can be documented and roughly estimated as well. A strategist will make specific suggestions for how we'll achieve the desired functionality based on the client's needs and budget.
Defining areas of uncertainty
Areas of low certainty should be clearly defined. Sometimes our project involves research that will impact the outcomes or decisions we make down the line. We can make (clearly labelled) hypotheses about desired outcomes, but for things of this nature we should focus on defining the goals of our research, and what goals will be unblocked by the discoveries we make.
Defining projected delivery dates
Delivery dates are heavily dependent on team availability, so they are commitments that should be made carefully. We can't commit to dates that will force our team into crunch mode or automatically cause us to disappoint the client, but we can be flexible to constraints from the client, too. Everything within reason.
Changes to delivery dates should be communicated to the client at least a few weeks in advance of the deadline if possible. Communication about delivery dates should make it clear what deliverable is being discussed:
- Is it the day we'll be ready to launch the project? (we shouldn't make launch promises at the start of projects, generally)
- Is it the day we'll be able to share a staging site where they can review our work?
- Are there any features that will be delivered later, or that are impacting delivery dates excessively?
Planning a project with a client is a negotiation, especially when it comes to timelines. We can be flexible, but they have to be flexible too!
Defining cost estimates
Tangible provides cost estimates ahead of starting work in nearly every case. Clients need budget commitments from us because they don't have unlimited money, and need to weigh the cost versus benefit of the project so they can decide whether it's worth pursuing. When estimates change, clients need to know as soon as possible, especially if work is ongoing.
🔭 Managing scope changes
Project scope defines the boundaries of a project: what it will include and what it will not.
When the client requests something that wasn't in the agreed-upon proposal, the scope grows, and this should be reflected in the estimates and proposal document and clearly communicated to the client.
🔏 Creating a proposal
Tangible's proposals are created in Google Drive using this template as a starting point.
A proposal document creates a reference point for conversations with the client during and after a project. It's a collaborative document, and should go through several stages of review and editing if required, until it represents a complete plan of the project's scope and budget, and technical implementation details, where required. It's a reflection of delivery goals that is in a format the client can understand.
A good proposal covers current project context, and our proposed approach to meeting the project criteria. It's a reflection of the delivery goals we've mutually agreed upon with the client.
It may take many meetings or email exchanges, and sometimes even a design phase to get all of the information we need to create a proposal. Once it's ready, we should book an appointment between the client and a strategist who's been involved with the project to go over the document together and confirm that everything is in order ahead of project kickoff.
🏗️ When to build a product
Often clients' requests for features are already achievable using existing software (WordPress plugins), and sometimes their requests are so specific to their way of running their business that they need a purpose-made tool just for them. In other cases, we'll often design a generic solution that we can offer to other clients in the future.
In cases where we're building a product, it's a good idea to loop in Julia.