Project Management Tips: Working at a Software Development Agency
Before I came to Flatiron, I was a project manager (PM) at a software development agency for nearly two years. Although that is not too long, the company I worked for was very small, so I had a high level of exposure to the in’s-and-out’s of how a software development agency is run. I also recently watched a presentation that covered a few elements of software project management, and as a result, was inspired to describe some useful takeaways for others to think about when considering working as a PM.
Before I provide more details, I would like to note that my experience as a PM, specifically at an agency, is quite different than one would have at a large company with an in-house team. Agencies play far more of a service-type role as opposed to an in-house team, which receives their requests internally. In addition, I would also like to note that I am not PMP certified, so although I have done a lot of project management work, I have no idea how much of these concepts fall into the curriculum of formal PM training. This is simply about some takeaways from real-world experiences as a PM.
Development agencies hunt for and receive requests from all sorts of clients, with a lot of variation from project-to-project. For example, at any given time an agency can have on-going jobs that range from managing a Fortune 500 company’s website, to building an iOS app for an individual who has the funding. All sorts of projects with many different goals come across the table. With that said, most agencies have some sort of specialty depending on who their team is composed of. For example, at the company I worked for, we specialized in building Headless CMSs.
Types of Projects & Contracts
The first process that I feel is important to describe, is how software agencies organize and manage their projects. Projects typically fall into to one of three different categories — “one-and-done”, maintenance, or both.
“One-and-Done”
A “one-and-done” project is when a client requests for a website or application to be built, transferred to them, and potentially never to be heard from again. In this case, once the product is completed and approved by the client, the project is over. For example, prior to when I worked as a PM, I was a worked on a mobile with a friend from college where we fell into this category. We ended up doing additional work beyond the original scope, but eventually we “cut the chord” and did not interact with them any longer.
These types of projects are scoped thoroughly for their functionality before beginning the project, so there is almost always a significant amount of deliberation about what the final scope is going to be. This includes all of the functionality expectations, as well as a timeline on the delivery of the various parts of the project. These segments that the projects are divided into are referred to as “sprints”. For example, a company would deliver the login page and user profile in Sprint 1, and the e-commerce marketplace functionality in Sprint 2.
Contractually, these projects are usually paid in increments, either by sprint or 50/50 (50% up-front/50% once completed). Occasionally they can be paid for up-front, but I can only imagine that making sense for a small project.
Maintenance
Maintenance projects can be quite varied, because ultimately they boil down to regularly updating and overseeing a particular application or property over a period of time. In addition, the nature in which an application or property is inherited has a big impact on the type of maintenance it will require.
In the case of having a maintenance contract without having completed the project originally, the agency is handed a completed or partially-completed application that they are now in charge of maintaining to a certain standard, and this can distill into a few ways. This process is known as inheriting “legacy code”, which I found to typically be referred to in a negative way, but that varies from case to case.
In general, when accepting a project like a website, for example, the agency will provide a certain set of updates that will keep the application up-to-date.
Website maintenance includes updating a site’s content management system, such as WordPress, Laravel (PHP), Umbraco (.NET), etc. In addition to the version of the CMS itself, every site uses different plugins that are updated at totally different times. The agency is typically responsible for keeping track of all CMS and plugin updates, and once one is needed, to deploy the updates onto a development environment where it is tested thoroughly. Depending on who the client is and what the website is for, the amount of testing necessary could vary greatly. In my experience there was a vulnerability test conducted, followed by round of quality assurance (QA) testing.
After the testing is completed, the deployment could vary, again, depending on the company. For an individual or low-traffic site, there would simply be a deployment to production. In the case of a larger company, such as the one I did projects for, we would push our clean code up to the Git repository of the security agency responsible for managing our client’s servers. The security agency then executed the final deployment to production themselves.
From a contractual perspective, a maintenance deal is stretched over a specific period of time, where an expected amount of updates are paid for over the course of a year. For example, a site-owner can expect there to be a WordPress update roughly every 2–4 months, so this would be built into the contractual expectations, along with plugins, data clean-up, etc.
Both
This project type is a combination of the two projects above, and is generally split into different contracts. One for the creation of the app or property, and another for the post-completion maintenance. As you might imagine, this is the most desirable scenario for an agency because not only will they make the most money from it, but the developers will also not have to deal with legacy code because they are creating it from scratch and then maintaining it.
Working Across Agencies
More often than you may believe, the software agency is not responsible for any of the graphic design for a particular project, unless they do it in-house. Similarly, depending on the nature of the property/project there can be many players, especially if there is a marketing campaign involved. Which if you are contracted by a large CPG company like I was, was usually the case.
On any given project you can have a specific agency responsible for the following parts of the project:
- Design Agencies (ex. VaynerMedia) — Design agencies have all of the creative directors and people who lead the design of a given campaign or site redesign.
- Security Agencies (ex. Infosys) — Responsible for overseeing all servers and facilitating deployments based on their best practices (FTP, GIT, etc.)
- Media Planning/Communications Agencies (ex. Havas, Dentsu Aegis Network) — There are a lot of rules when it comes to saving user’s information into a Database. Especially with GDPR (General Data Protection Regulation) put into play in the UK (where the company I was contracted to was based out of). The penalty for blatantly violating GDPR can result in up to a €20M fine or 4% of annual revenue — whichever is larger. So these companies take user data management very, very seriously.
- SEO Agencies (ex. iProspect) — When a project is proposed by a client, very often there will be a company that specializes in SEO, that provides header-tags and strategies for search-engine optimization. For example, non-branded pages perform better.
- PR Agencies — Specifically when it comes to running Sweepstakes or Competitions, which have different regulations respectively, there are companies that know the in’s and out’s of those regulations very well and help clients avoid getting sued. For example, if you register a sweepstakes where there is evidence that users do not all have an equal chance to win, you can be sued for a lot of money. Every agency involved in a given project needs to understand these rules before jumping into production creation/launch.
Red Flag Chart:
Sources:
