At The Commons, we split our time between a mix of product development sprints that add features to our existing platforms and application development projects where we work with clients to integrate our platforms into their programs to achieve their goals. Regardless of the project type, our entire team pitches in to get a project or sprint from start to finish. A small team makes communication and management easier. A small team also means that we all wear a lot of hats and keep a lot of balls in the air. Rather than turn The Commons into a Circus*, we have guidelines that keep our operations and teams running smoothly.
* Let’s be clear, actual circuses are well-run machines that put on an incredible show to their customers thanks to hours of practice, dedication, and talent. We have no beef with real circuses and can’t wait to go to a real one again someday.
In our case, we rely heavily on planning out and adhering to road maps, deployment schedules, and work scopes to keep us all moving forward, hitting deadlines, and delivering exceptional results to our community and clients. Getting to this place of pushing forward more projects than we have people simultaneously has taken a lot of project management acumen, trial and error, and deep conversations as a staff and with our clients. From those lessons learned, we have built a structure that we easily apply to all of our projects.
For those that are looking to conduct product application development work, we have lessons learned to share with you about our process. In this post, we will share some best practices that work for our team and clients. If you embark on this work, take these tips to heart so that you don’t have to learn the hard and expensive way.
We will start by explaining the difference between our product development sprints and application development scoping process and then dive deeply into best practices for creating a skeleton of a work scope.
Product Development Sprints: Our Process
For development sprints, our software engineering team deploys an agile development approach to build, iterate, and complete their sprints.
This approach has worked wonders for our team and over the years we’ve been able to refine a process and routine that reliably pushes features through our development pipeline systematically and structurally with minimal tech debt or excessive lingering bugs and barriers to usability.
The following provides the non-development perspective of the project strategy that we use.
We start with discovery and visioning sessions internally or, if relevant, with the funders supporting the development of the feature set. Based on the provided information, our lead software engineer will scope out a timeframe, necessary resources, and key milestones to hit in order to complete the feature. Once we have a general understanding of the goals, our development team also creates wireframes and high resolution mock-ups of the work to be done. This information is shared across all participating team members for review and discussion. Ideally, any roadblocks or key concerns will be addressed at this time in order to give our developers room to iterate before writing too many lines of new code. As work progresses, the team tracks all key tasks using our project management system: AirTable. We jump on weekly check-ins to discuss progress as a team and have a calendar of check-ins scheduled to meet internal and external expectations. To be true to the agile nature of these projects, our software team routinely tests, reviews, and reassess while sprinting through the required work.
Finally, at the end of a project sprint, the entire team will jump onto our development servers to kick the tires, document and address bugs, and begin the fun task of familiarizing ourselves with the new platform feature. After addressing any questions, the feature is pushed to production and the team moves on to the next project. It’s imperative to identify components of a project that appropriately lead out (ready for a sprint) versus a longer term carry for a product. For example a client may have a great feature idea that is broader and overly reliant on the developer to figure out all of the implementation details on. In this case we don’t say “no,” we say “not yet.” It’s not fair for us to write of the feature as a bad idea but it is fair for a developer team to say “I don’t know how to implement your vision because it’s not clear enough for me to execute on.” In this case more shaping is required and its a longer term lead-out that will eventually turn into a sprint when the timing is right.
Product Deployment Process
Our second class of work involves taking our products and working with clients to apply them to their programs. The process for managing a project with a client is categorically different from how we step through our feature development process.
Typical application projects that our team takes on include:
- Setting up new funding programs in FieldDoc
- Setting up a regional water quality monitoring data ingestion and visualization strategy
- Digitizing an organization’s historical water quality monitoring data to begin storing and collecting data in Water Reporter
- Building websites dedicated to showcasing water quality monitoring work
Regardless of the project type, The Commons relies on a Scope of Work to standardize the operating expectations both internally and externally for the work we intend to undertake. Over the years, we have experienced first hand how a SOW is worth its weight in gold. While some of the projects we think we could do with our eyes closed at this point, we continue to create and share SOWs with our clients and internally for each and every project. This sets the stage for expectations, deliverables, and timelines immediately after initial discovery and visioning sessions and helps all stakeholders keep on project target.
Not to belabor the point but, our SOW is a critical business tool that we use to both define our work and hold all stakeholders, ourselves and the clients, accountable. The SOW is our guiding document for the project at hand. The document helps our team stay within budget, build client relationships, manage expectations, and manage internal employee satisfaction.
Fitting a SOW into a project
When to build a SOW matters. If you walk into a first client meeting with a completed SOW before hearing about their needs or expectations, you’re implying that you’re not willing to listen or let them weigh in on the process at all. Our job as creators and makers is to listen often and listen closely. Visioning and discovery sessions give us an opportunity to ask questions and spend time getting to know the client and their needs. As such, we only create and share a SOW with a client after the initial discovery calls have occurred, even if they ask for an ‘off the shelf’ type project.
Once a SOW has been signed off on by all parties, we treat it as the final word and itinerary throughout the project period. We aim to meet expectations and deliver satisfactory results. To achieve this, we keep our SOWs close on hand and available to all staff participating in the project. We want to make sure that our entire team can reference not only the tasks assigned to them but where they fit into the bigger picture and goals. This helps us all take ownership of the project and work together through the nuances that will deliver exceptional results.
Characteristics of a Commons SOW
Regardless of the proposed work, a Scope of Work delivered by The Commons should always aim to be:
Concise and clear. Our SOW must be accessible and readable by clients regardless of their technical expertise. The straightforward document will offer a clearer path towards success for project completion and adoption.
Complete. We offer a thorough project plan that understands the clients end goals and considers all of the components necessary to get over the goal line. This will aid not only our team in successfully delivering the work but will also build a strong relationship grounded in mutual trust with the client.
Conclusive. We want to clearly communicate to our clients what we will do, why we are doing it, and how we will do it. Clients should walk away with all of their pre-project questions answered knowing what they will receive at the end for the agreed upon price and not hoping for more or expecting something different. While our team strives to be accommodating, a signed Scope of Work has no more room for negotiation and should protect our team from project creep which will, in turn, keep us within budget and on track to deliver expected outcomes.
Deploying a Scope of Work
As previously mentioned, most projects will involve all staff at some point in time. We strive to maintain a strict development and deployment process for each project that we take on in order to keep catching all of the balls that we are juggling. Our structure may appear laborious but we have found that getting buy-in and approval throughout the project period does wonders for staff satisfaction and success on projects.
Internal SOW preparation and signoff structure
- Introduce the project. Introduce the proposed work at a scheduled team meeting and get any high-level initial input or feedback and confirm that the team wants to pursue this project. This should happen after the lead has already had a discovery meeting or three with the client.
- Draft scope main components. Based on that conversation, the project manager writes the draft scope of work keeping in mind how the work aligns with any existing roadmaps and other competing work for staff’s time. The project manager sets boundaries such as budget constraints, critical timeline components, and expected deliverables before passing along the scope to the project team to provide closer detail for tasks.
- Define project tasks. Project SOW should be shared with team members/team leads who will be responsible for main deliverables to flesh out the necessary tasks and timeline. Their feedback should be incorporated into the SOW.
- Internal Sign off. Before the finalized SOW is shared with the external client, all team members with a stake in the project should have at least one business day to sign off and review the document and proposed work.
- External Review. SOW shared with the client. Any updates need to be reported back to the project team before signature.
- Log the Project. Final SOW and budget should be saved in the correct place in the Google Drive and logged in the AirTable Project and Grant Index.
- Set up Tasks for Management. Project Manager should create a project in the relevant Airtable workspace and enter in all tasks as activities. Throughout the project period, project progress should be recorded in AirTable and project meeting conversations should be documented and stored as a conversation summary and next steps.
- Project Reporting. This will follow the schedule agreed upon in the SOW and contract.
- Project Wrap Up. At completion of the project, the update team and project lead writes up a summary of the project. Collect any feedback or materials from the client. Determine if there are next steps and the timeline to ‘check in’ or start the next phase.
Scope of Work Sections
Finally, let’s take a quick look at the sections that we make sure to include in our scope of work. While we have a goal of being concise, we also aim to be both clear and conclusive. This means that the SOWs that we share with clients tend to be a bit long. Thanks to how we structure each document, however, anyone reviewing it can quickly navigate through to the information they need without jumping all over or only getting piecemeal information. We want all stakeholders to fully understand the project being undertaken.
Sections 1–3 are the anchors to lay out all of the work to come, that’s why we put them at the beginning of the document.
1. Project Overview
We give each project a working Title
2. Project Timeline
Cleary define when will the project start and end.
3. Cost
Final Budget amount. Link to detailed budget template.
Sections 4–6 Deliver a three-part narrative on the purpose of the project. For many stakeholders, this is the information that will confirm that we are on the same page for project expectations and deliverables: that The Commons understands their needs and that we have a plan for how to deliver the solution.The information provided here should speak to a general audience, starting with broad strokes before narrowing down to specific tasks and outputs.
4. Purpose and Introduction
In 150 words or less, state the project plan and ultimate goal.
5. Project Overview and Business Objectives
In 300 words or less, state the problem and how the project will solve it. By providing ample writing room we can include the context of the problem, how it arrived at its current stage, and an overview explanation of the project itself. The explanation aims to lay out the foundations for how this project will solve the problem. We aim to include any known business objectives of the client and what outcomes will be achieved. This should be the most straightforward written section with a reliance on simple language and aversion of highly technical or scientific jargon.
6. Scope of Work
This section moves from talking in generalities to exploring specifics of the work, stating specific objectives aligned to achieve the overarching project goal.. In this section, we state each of the objectives and provide a quick narrative elaborating on the objective as well as any visuals to help fully capture the information. Each of these objectives will be broken down in the Activities and Tasks section below.
Creating objectives can be hard. A lot of experts recommend sticking to SMART objectives and reject those that don’t meet the simple, measurable, achievable, realistic, and time-bound criteria. At The Commons, we are not bound to SMART objectives, sometimes a SMART objective doesn’t feel possible. We avoid nebulous objectives and aim to include a clear connection to the project goals.
7. Activities and Tasks
This section holds the majority of the details for the day-to-day work as it will be undertaken by all stakeholders. We stick a lot of information into this section. We break our work down into phases, tasks, check-ins, milestones, and deliverables below each of the stated objectives. We adhere to a waterfall approach for each objective, unless otherwise noted, but often our objectives have overlapping schedules and timeframes. We have structured our tasks in a way that is very easy to migrate into AirTable. It aligns directly across the SOW and the project management software.This makes check-ins, report outs, and progress markers easier to keep a handle on for all stakeholders.
Tasks answer the questions, What exactly needs to get done to meet those objectives? What milestones must be met to keep the project moving towards completion?
Tasks should be specific and spell out at a granular level the steps taken to achieve the objective. For bigger projects, we often segment tasks into phases and identify the order in which things have to happen. For example, we may define phases such as “kick off”, “design”, “build”, “test”, “training”.
8. Expected Outcomes and Adoption Plan
This section summarizes the answer to your problem statement in section four. Based on all of the objectives and work undertaken, what will this project achieve?
We spell the answers to this question out in a section after the tasks to help clients see where to go from here. We value the assistance that we can provide clients in taking the finished product and how the clients will take ownership over the long term. By setting expectations on the training and support that we will provide, clients begin to fashion their own strategies for making the most out of the project and confirming that they are putting together the strategies and objectives they need that will measure their success at integration of the project beyond what The Commons delivers, and not confusing the roles.
9. Terms, Conditions, and Requirements
We have found that we should make the fine print a lot bigger and more noticeable as well. And to make sure that all stakeholders are truly in agreement about the work to be done, we include a terms and conditions section. In this section we look at reporting, assumptions, and exclusions.
10. Reporting
We include check-ins in section four but we also like to include reporting commitments in our SOW. This more formal process gives everyone a backstop to point back to as the project nears its completion. Reporting summarizes the work progress through a written, shared document. If the client has any concerns or questions or needs to put the breaks on the work, the multiple check-in types gives them ample opportunity to review and speak up about their project. A lot of our projects have this language included in the contractual agreement, so by adding it to the scope of work we are not adding more work to our plates, just consolidating where the information is located.
11. Terms: Assumptions and Exclusions
After you’ve been doing these sort of projects for a while you start to see some trends that indicate which clients are going to take the project and run with it as is and which ones are going to try to keep asking for “more” outside of this original scope. The assumptions and exclusion sections attempt to clarify any lingering questions surrounding the project. Some of the items listed here probably arose during the discovery phase but some are just common pieces of knowledge or advice that are best left said, not unsaid. For example, at The Commons, we do not white label our projects. Unless explicitly stated and budgeted for, we don’t make changes to our platforms in application projects. And we offer ongoing support, maintenance, and access to feature updates to all stakeholders for as long as they retain their subscription fee.
12. Success Criteria/Sign Off
When is a project done? When we have reached the end of a project, we return to the two principles to confirm completion. This lets everyone know that we’ve completed the project and we are now moving forward with whatever agreement was made for continued maintenance and support. Many of our projects happen in phases, so this may be the time that the client goes out to fundraise for the next phase. Regardless, we like to keep the sign-off process simple but official so that we can close our books.
Final Common Thoughts on Scope of Works
Getting this agreed upon up front might seem unnecessary, but it helps reduce the chance of serious headaches later on when you receive something that isn’t what you expected. Remember, a SOW is all about clarity and detail. The more you give, the better result you’ll get.
