Project Management isn’t an easy thing.
Managing projects across several different companies isn’t any easier. Here’s the process I’ve created and nurtured that makes my job at Hayseed the most exciting, challenging and smooth operating position I’ve ever held.
Hayseed Ventures is a VC production studio located in the heart of downtown Fayetteville, Arkansas. Our mission is to turn promising startups into full fledged businesses. We work in the trenches with our portfolio companies on a daily basis. We like to say that Hayseed “checks the last few boxes” on a startup’s list of must-haves. My job is to be project and product manager across these various joint efforts.
This blog post outlines my entire framework for managing projects. It’s an attempt to solve the difficulties and challenges of excellent quality project management without a need for drag inducing components like massive spreadsheets, time logging, spec sheets, Gantt charts or other systems like those. You don’t need them with this framework.
At Hayseed, I work with several different teams, personalities and team dynamics across multiple companies. Having a single process at the core of these efforts is crucial so that I don’t have to change my tools, mindset and process as I hop from company to company.
Sometimes I change which company I’m working with on an hourly basis. Keeping track of all of this in my head would be impossible. That’s why I adhere to this framework like it’s law.
I’ve broken out my process into what I believe to be the major parts of project management: requirements gathering, status tracking, stakeholder updates, iteration planning and the project retrospective.
Requirements Gathering: User Stories and Epics
[blockquote text=’User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.’ text_color=” width=” line_height=’undefined’ background_color=” border_color=” show_quote_icon=’no’ quote_icon_color=”]
[blockquote text=’Epics represent significantly larger bodies of work. Epics are feature-level work that encompasses multiple user stories. While a user story might involve an add to cart button, an epic would involve the entire cart page.’ text_color=” width=” line_height=’undefined’ background_color=” border_color=” show_quote_icon=’no’ quote_icon_color=”]
When working on gathering what’s needed for a project, I put my focus on all actionable user stories and larger epics regardless of whether they’re development requirements or not.
In other words, I put time and effort into gathering not only the base user requirements but all of the actionable items in a project. These could be operational or development tasks, marketing efforts or brainstorming sessions that are certainly needed in the future.
Ensuring that I capture all of these details helps me plan out what I need to do and helps me see problems that may arise along the way. If I were to just capture the software requirements, I would be missing half the picture!
The initial requirement gathering is done during an intensive storycarding session involving major business stakeholders, developers and the Project Manager.
This process takes some time, so I also like to recommend setting aside an afternoon or two to ensure everything needed for the project is captured.
At Hayseed, we run very lean in our project management — so unlike true Agile, there are no “Story Points”. In my experience, teams eventually gravitate towards the “everything is a 3” trend anyways, so why include such a superfluous metric? I’ve also found that having story points can lead to stakeholders pushing the mantra of “Oh surely this feature is a 2, shouldn’t I get it quicker?” position. You don’t want that.
I like to shed the drag that story points put on requirements. Replacing it with weekly sprints full of cards that the team knows it can get done is far more effective. I’d much rather be able to show a week’s worth of work to stakeholders than try to explain why a ‘1’ was really a ‘3’ because of some intricate technical issue.
Project Tracking: Trello (or other Kanban style app)
Trello is a fluid project management application that can adapt to any company, team or project.
It’s based around a system of cards and lanes which represent the stories and what status those stories are in. It’s what I use for tracking projects and what I will always recommend to any Project Manager who’s looking for a tracking tool.
I attempt to use as few lanes as possible to track my cards. These lanes are:
- Pending (To-Do)
- Work In Progress (WIP)
Move your cards between these lanes as it transitions states. Flag your stories with labels and add team members to their individual cards. Trello has tons of features that make tracking projects easy.
I track all of my projects and even my personal work through Trello. It’s invaluable to my process but I realize it doesn’t work for all people. Other Kanban style apps or even a whiteboard with lanes on it fits this style of Project Management.
Tracking is mostly for the benefit of the Project Manager; if you stay on top of it, you’ll be able to rattle off the status of any number of things to any interested stakeholder. Since the tracking tool is for the project manager’s benefit — don’t let others dictate what tool you use.
When I was at Acumen Brands, at the drop of a hat, I could rattle off what any one of 12 developers was working on, down to the individual status of the card they had in their WIP lane. I owe this to our streamlined use of Trello. It became super helpful when prioritizing work and building the backlog while sitting with the stakeholders.
Stakeholder Updates: Small Stand-ups
Keeping stakeholders up to date is a daunting part of any project manager’s life. It’s key to keep those who care up-to-date and to address questions or concerns they may have. It’s difficult to get time on a busy stakeholder’s calendar and to ensure that all of the right people can make that meeting.
It’s also crucial to get any requirements changes captured and in the backlog and feed that back to the developers.
Hallway conversations and lengthy meetings with 15 people aren’t the place to update stakeholders. These will result in scope creep and changing requirements which snowball into delays and unhappy stakeholders.
Fast, informative and frequent 10 minute standups are exactly what needs to happen. These should ideally be once a day, but no more than twice a day. If your stakeholder needs that many updates, something else in your process is broken.
These small standups help keep stakeholders in the loop and can also catch deviations from what the stakeholder wants extremely early. If I mention a feature that’s going to be working one way as implemented and stakeholder had envisioned something else, it can be caught much earlier than if stakeholders just reviewed a release or were updated at the end of a sprint.
Iteration: Return to Step 1 This is the all-important planning step. Once your team has knocked out everything in your “To-Do” lane and it’s been signed off by the stakeholders, it’s time to plan the next iteration.
Here you’ll have another, shorter “storycarding” meeting where you take direct action off of the previously completed iteration. Move cards from your “Icebox” into the “To-Do” lane and repeat the process!
Be sure you cover every card in your review lane, talk about challenges you may have encountered in the previous iteration and also cover any snags you may see coming up in the next iteration. Communicate clearly and transparently to your stakeholder. Demand feedback and get eyes on all work from the iteration, don’t let this step slip by. The sooner problems are caught, the quicker you can rectify them and have happy stakeholders.
Iterating is easy: Gather stakeholder feedback. Create storycards off of this feedback. Set backlog. Move into action and get stuff done.
The Retrospective: Review, Learn, Celebrate.
After a project is completed, take some time to celebrate your launch and then get right back into the fray — send out the meeting invite for a retrospective.
Get your team in a room and talk through all aspects of what you just accomplished. Share detailed learnings, congratulate team members who excelled and figure out what to do better next time. This is a time to air out grievances and determine steps to avoid repeating mistakes.
Deliberately celebrating wins is very important to creating a tight knit team atmosphere. Teams often forgo the retrospective and tackle their next project in the exact same manner as the previous one. This is toxic. Learning what you did wrong and right is just as important of a step as requirements gathering.
For any business, process is important. Understanding that process isn’t set in stone is more important. Don’t take my process as law. Your mileage may vary and you may find your stakeholders respond better to a slightly different format. However, adapting my general guidelines to your own workflow shouldn’t be hard and I guarantee you’ll see a benefit from it.
Project management is inherently fluid and this framework can support any number of different project tracking tools and can be scaled for the smallest of teams to the largest of initiatives. It’s based off my learnings from Acumen Brands (where I sat between a dozen or so developers and as many stakeholders) and it has been tweaked for supporting multiple different teams.
This entire process is built so that one person can manage many projects at once, something all PMs will need at some point and something I’m intimately familiar with at Hayseed. Overseeing multiple projects across multiple companies forces the creation of a framework like this one.
In the end, project management isn’t about your tools. It’s about communication. It’s about taking quick, informed action from feedback and acting on it in short, rapid iterations.
Keep your process lightweight and you’ll see great results.