A little over a year ago I walked into my new Project Manager position at Electric Citizen (“EC”) excited, nervous, and ready for new challenges. I knew I had the skills to do the work and do it well but I was nervous that my colleagues and clients would see right through me.
Prior to EC, I worked at one of those fast online design companies where you pay a small amount of money for a predefined product. I was the sole project manager for all website projects, managing a small team that cranked out 8-10 new websites a month. But I often felt like I was making it up as I went along.
The first few months at EC were a whirlwind of new terms and processes. I’d see a Slack from one of our developers about a bug on a site saying something like: “I see what you are referring to on dev, but can’t reproduce on local.” And I’d think, “What’s a local?” and immediately set off to Google. While I had a baseline understanding of different development environments, I’d never heard of local development.
At the same time, I wanted to deepen my knowledge of project management methodologies and practices, so I joined the Twin Cities Interactive Project Management group. I attended Manage Digital, founded by a friend of EC’s (shout out Lynn Winter!), a day-long conference focused on connecting and inspiring Digital Project Managers (“DPMs”). I also started reading everything I could on The Digital Project Manager and even joined their Slack channel, which allows me to exchange advice and ideas with other DPMs around the world.
What I quickly learned is that I wasn’t the only Project Manager out there who sometimes felt a bit like an imposter. I was very much walking the walk, but I wasn’t talking the talk. Sure, I could only guess at what other DPM’s were saying about when they would talk about the challenges of “resource planning,” but I had been managing budgets and scheduling developers and their work for years. Which *spoiler alert* is basically the same thing!
All of this made me realize that in order to become a confident PM, I first needed to feel like a competent one by beginning to use the right lingo. To that end, I’ve put together a handy list of what I think are some of the most helpful terms to learn when it comes to managing digital projects and being a part of a web development team:
SoW
SoW refers to a Statement of Work and is a document that outlines an approach to a project and the specific deliverables to be completed as part of that project. The SoW often lives within a formal contract and is used to drive the direction and activities of a project. SoWs sometimes change and need to be rewritten, as an understanding of the project grows or priorities shift.
Proof of Concept
In some ways, a Proof of Concept is similar to a SoW in that it’s a document that describes an approach to a project and how you’re going to get from point A to point B. At EC we use proofs of concept to provide details on a specific feature of a project. This allows us to dig into the necessary details of often complex integrations or features. These documents usually include the goals for the project, the specific approach that will be taken to complete it, as well as defining project success.
Scope
Scope refers to what a project should achieve through outlining activities to get there, as well as specific features that need to be built. The scope should always be based on the goals of the website and the needs of the site’s users. The scope should also relate to the budget for the project and attempt to align with it in a realistic way. There is a close link between the scope and the SoW and many PMs and agencies talk about “scope” when referring to what’s outlined in the SoW.
Scope Creep
Scope creep refers to when project requirements start creeping outside of the agreed-upon scope. This often happens when new features are added, or more complexity is added to an existing task. Scope creep has an impact on a project’s budget and timeline, and as such needs to be addressed by project managers and web teams early and often.
MVP
Minimal Viable Product (or MVP) in the context of web development is referencing the product you are going to present to your client. Many times we use the concept of MVP to help determine with a client the product or work that gets done within a specified budget and/or timeframe. A great example of this is a client that may be requesting a ton of new features on a website redesign, but really only has the budget available for half of them at the moment. So, together with the client, you would determine the minimal amount of features you can complete within that budget and that’s your MVP. If you end up having time for more, great!
KPIs
A key performance indicator (or KPI) allows you to define what will make a successful project. They give you the benchmarks for which to measure work against. These indicators should be quantifiable and could include things like improved site speed or increased site traffic. KPIs should be written in collaboration with a client and agreed to at the beginning of a project.
Time and Materials Billing Method (T&M) vs. Fixed Budget
Web agencies typically bill their clients using one of two approaches. First, there’s the time and materials method (T&M). With T&M the agency bills the client based on the amount of time worked by their team plus the cost of materials used. This method allows for flexibility in a project, but can also be difficult when it comes to budgeting for the client.
A fixed budget or fixed price method is when all project costs are determined upfront. Often this means agreeing to a set number of hours for all of the different phases of the project and features on the site. At EC we love working with civic-minded organizations which include nonprofits, higher education, and government, so a fixed price method is almost always a requirement for those clients.
Retainer
A retainer is an agreement between an agency and a client, where the agency promises the client a set number of hours per month that they’ll do work. While we don’t commonly use the word retainer at EC, this type of work and billing comes in the form of our support plans. With our plans we offer our clients different options to meet the level of support and necessary maintenance that is right for their needs and budget.
Project Management Methodologies
Good web agencies follow some sort of specific process for managing their projects in a way that is effective for both their team and their clients. My favorite PM resource thedigitalprojectmanager.com does a much better job then I could explaining some of the major ones in their article on Project Management Methodologies Made Simple. It’s important to note that most agencies actually use some sort of hybrid of these as we do at EC!
Sprints
A sprint is a period of time, typically 2 or 3 weeks where a team works to complete certain tasks pulled from the backlog (see next term). At EC we use sprints so that we can be flexible, but more importantly so that we can release different features of a site early and often to our clients. This allows us to not have a mad dash of changes and requests at the end of a project, but to work them in naturally as the web development process continues.
Backlog
A backlog is basically a list of all tasks that need to be done to complete a project. At EC we use a software called Jira to manage our backlog in the form of tickets that then get pulled into sprints as it makes sense and as they align with the goals of that sprint. We also use the backlog for support and maintenance clients for continuous improvement tasks, essentially work they know they’d like to do at some point but aren’t quite ready to tackle yet.
Resources & Resource Planning
Resources are essentially everything you need to start and complete a project. For most agencies, resources refer to people, time, and money, but it could also include equipment. Resource planning can encompass a lot of things and can get pretty granular, especially depending on the size of the agency and type of work they do, but for our team, it usually comes down to scheduling work and managing budgets. Trust me, that may sound simple on the surface but effective resource planning means projecting into the long term and mapping out current and upcoming projects, the hours involved with them, and the people that will complete specific pieces of work. Resource planning is a huge part of a DPMs role because resources have to be reallocated frequently based on how current work is going, as well as ever-shifting priorities.
Full disclosure: I still don’t use the term resource in my daily work life. I have an educational background in psychology and the idea of referring to the people on my team as resources feels a bit too impersonal for me.
Web Developer Roles
While I would guess that anyone reading this post is familiar with what a web developer (or Dev) is generally, it is important to know that Devs often specialize in specific areas (though their roles are starting to blur together).
- Front-End: This is the Dev who works on the part of the website that you can see. They are typically concerned with implementing designs in collaboration with UI/UX and creative teams. They focus on how to make the interface functional and attractive to the user.
- Back-End: I like to think of the Back-End Devs as the wizard behind the curtain. They are writing code, managing the back-end database, and implementing technical architecture to ensure that everything on your site works. They typically don’t concern themselves with the visual appearance of the site, but want to ensure that every feature and process on a site is functioning as a user would expect and need.
- Full Stack: There’s a quote that says, “A Jack of all trades is a master of none, but oftentimes better than a master of one.” A Full Stack Dev really fits that description. They are someone who has a level of familiarity and comfort working in both a front-end and a back-end capacity.
Development Environments
Developing in different environments ensures that your work and associated code is tested and stable before appearing on a live website. This is especially important when you have multiple people editing a site or when a site has a lot of complexities to it.
Prior to EC, I was familiar with the standard environments of development (dev), test (sometimes referred to as staging), and production (or the live site), which can be boiled down to:
- Dev: This is where you develop code and add and edit content.
- Test: After you’re feeling good about your work on dev, you move that work to test to review and QA before pushing your new work live.
- Prod: This is your live site and work should only go here when it’s been tested and is fully functioning.
However, the development workflow can vary based on processes at a specific agency, as well as the needs of a site. For example, a simple Squarespace site isn’t going to exist in multiple environments - you do everything on live and cross your fingers nothing goes wrong! At EC, we know that developing locally is the best practice in web development. This means before a developer on our team gets to work, they pull a copy of the live site down and install it directly on their computer. They do the work there before pushing it back up through the development process outlined above.
DevOps
DevOps, which is short for Development and Operations, refers to work by a Back-End Developer to automate processes to make development work more streamlined and efficient. The extent of this work really varies by agency and the type of development they do, but can include things like automating the process of spinning up websites for new client projects, managing local build environments, and creating automated processes for testing and deploying code. If you want to learn more about DevOps in Drupal 8 check out a post by EC's very own Tim Broeker.
Cache
Caching is the process of a web browser temporarily storing data for use later, such as images or parts of a page. The basic idea is that we want websites to load quickly and grabbing a file from your browser is faster then pulling it from a server. When a change on a site isn’t being reflected, DPMs and Devs will often ask a client if they’ve cleared their cache because chances are their browser is storing outdated files. Clearing the cache will ensure that you are viewing the latest content on a site (and so often clear up what you think is a bug).
The best approach when it comes to terminology is to agree on a shared language with your clients and your team.
The number one reason that knowing the right terminology for your industry matters is that it helps you to get on the same page with the people working around you. It also helps you to connect to others in your field.
That said, there are times when using the “right” terminology can alienate your client or team and leave them clueless as to what you’re talking about. In many cases our clients are not other web developers or project managers, rather they are people focused on the work of their specific organization in their own industry. They are often using terminology that we’re not familiar with either because we don’t work in that sector.
The best approach when it comes to terminology is to agree on a shared language with your clients and your team. If your client doesn’t know what a sprint is, walk them through it. If your team doesn’t like to be referred to as a resource, well call them something they do like.
Join the Discussion +