Originally published on the CURTIS Digital, Inc. blog.

Buying Tech is Hard: Project Plans Don’t Equal Software Requirements

Welcome to Buying Tech is Hard! In this series, we’ll explore different ways to help ensure you feel empowered during the entire software purchasing cycle. Whether you’re still vetting agencies or about to officially kick off development, working with external vendors can be a roller-coaster of emotions. We want to give you the tools to succeed!

Being a manager isn’t easy. Many of our stakeholders are marketing and project managers, and we know how difficult the job can be. Keeping track of everyone else’s work is no small feat, especially when you have an external agency to manage as well. Analyzing dependencies between internal team-members and vendors can quickly grow overwhelming, and in that state of confusion, many people turn toward tools that have brought them clarity before: namely, project plans.

Traditional project plans have undergone a revitalization in the last few years. While Microsoft Project still reigns supreme, a variety of similar, SaaS products have appeared on the market as well. Smartsheet is a popular one among our clients, but WorkzoneEasy Projects, and TeamGantt are equally popular solutions. Our project management team receives invitations to these systems quite regularly. Although it might sound surprising, we’re often reluctant about accepting the invites. Why, do you ask?

Put plainly, project plans are not task management tools. If we had a nickel for every time one of our PMs opened a traditional project plan only to be met with a list of tasks, we’d be able to help a whole slew of startups with their Series A funding.

While traditional project plans can help forecast deliveries and track dependencies, these “task list” project plans are the perfect breeding ground for confusion and bad habits. If you absolutely need to use a project planning tool with an external agency, make sure you’re doing so correctly.

Here are 7 key ideas to keep in mind before you invite your vendor to join your project plan tool:

1. Task Names Don’t Equal Task Descriptions

The structure of a traditional project plan gives you about a sentence of space to describe what task is going to occur. However, these high-level task names don’t include the actual “meat-and-potatoes” of what a task involves. For example, we often see line items like “Implement search” or “Update the homepage” as specific steps in a project plan. While you might know exactly what these items mean, there’s a good chance that your agency doesn’t. How are they supposed to implement search? What specific items need to be updated on your website homepage? With software, the devil is always in the details. Unless you are explicit with your agency about what you need, you’re opening yourself up to the possibility of a misunderstanding (and in turn, a potentially larger bill).

2. External Agencies Don’t Know Your Internal Lingo

A good software agency strives to make themselves feel like they’re part of your team. While your interactions might feel seamless, it’s important to remember that they aren’t actually on your company’s payroll. They won’t know your internal culture, and if you’re in a different industry than they are, they likely won’t know jargon common to your field. Whereas “SQL” might mean “Sales Qualified Lead” to you, it means “Structured Query Language” to a development shop. While an agency might be able to quickly decipher what your task lists are actually asking, important details can get lost in translation.

3. Be Prescriptive

Being prescriptive is related to points 1 and 2, but it is important enough that it justifies its own section. It’s not uncommon to request ideas that aren’t fully formed. We’ve received our fair share of “make the text blue”s and “can we make this font smaller?”s, but these statements are actually more complex than they initially seem. There are over 16.7 million different web colors available to choose from—when you say “blue,” do you want your text to be #003D66 or #006BB2?

Being prescriptive means your agency doesn’t have to guess what you want. Even the best dev shop won’t be able to intuit what you want 100% of the time, and misunderstandings can cause unnecessary friction.

4. Lists Are Visually Overwhelming

When project planning software is used as a task list, the list quickly becomes overwhelming. As tasks are completed, they often receive a status of “Completed” or “100%”, but they don’t necessarily fall off the list. That means you and your dev team are weeding through your project plan looking for what exactly they’re supposed to be working on. This makes it easy for items to get missed.

5. Lists Imply Something, But What Exactly Isn’t Clear

Are newest tasks placed at the top or the bottom of the list? Where are urgent items tracked? Each company has their own way of structuring task lists, and chances are that you’re agency does so differently.

6. Project Plans Should Point to a Spec Doc – Does Yours?

Project Plans aren’t intended to be used in isolation. Tasks should always point to either a software specification doc or a specific user story where your development team can find the more prescriptive task description. Without this, your trusting your agency to keep track of every detail about the task that they’ve gleaned from emails and calls. A good agency will collect all the information they receive and store it in their own ticket tracking system, but that leaves you in the dark about whether or not they captured your feedback correctly.

7. There Are Better Solutions

Every time we kick off a new project, we invite our clients into our Jira system. Many find it overwhelming and opt never to join, which is a real shame because Jira provides the most up-to-date information about the status of each task. While Jira can have an initial learning curve, it truly gives you the clearest picture of what’s going on in your project. Every task is organized by priority and assigned a certain amount of hours. Then they’re sorted into columns based on their status – to-do, in progress, in QA, stopped, etc. That way every time you log in, you can immediately see what items require your attention and which are still being worked on. Jira tickets have robust fields for task descriptions, they allow you to upload attachments, and you can leave comments on them. None of these features are readily available in a project plan.

If Jira feels too overwhelming, give Trello a shot. The setup can be completed in a few clicks and allows you to create a digital “to-do” list with customizable columns.

We’ve also recently begun exploring Airtable, which describes itself as “part spreadsheet, part database and entirely flexible.” So far, we’re loving it. Keep your eyes peeled for our upcoming blog post which explores why we decided to try Airtable and what we’ve found so far!

Conclusion

Don’t get us wrong. We love project plans. When used correctly, they can be incredibly powerful. There is a time and a place for every tool, but you wouldn’t use a hammer to try and unscrew a screw, would you? Then don’t use a project plan to try and manage tasks! There are better solutions out there for you to help ensure you get exactly what you need from your software team. And when you’re getting what you need, chances are you’ll be less likely to want to rip your hair out. Software development can be stressful, but having clear and defined tasks is something that you have control over. Don’t relinquish that power because a tool like Jira or Trello seems intimidating! You’re paying your agency for guidance; let them guide you.

Let us know in the comments below what you do to solve some of these obstacles.

Previous
Previous

Enterprise Game Stack Overview Video Script

Next
Next

Agile Burndown Charts and Why You Need Them