Published in · 7 min read · Aug 30, 2017
--
A few weeks ago, I wrote a post about PM-ing here at G Adventures (I feel legit using abbreviations for “Project Management” now because I wrote that post, makes me feel all empowered). It was mainly centered around how our environment is a finicky one when it comes to using PM tools, principles, leveraging due dates and sticking to them, reporting, scheduling… actually, give it a read here if you haven’t — it’ll help make sense of this post.
Anyway, what I would like to center around is processes and all the things that go with it. Before I even dive into something of this caliber, especially given the content of the last post I have to start off by saying that much like PM tools and principles being new to us here at G, it’s pretty much the same with processes. It seems to be a scary word almost in our waters.
To ensure that we’re all on the same page — by “processes” I refer to the behaviors, steps, and actions taken in order to achieve a particular end. This includes (to start with) team meetings, how projects get requested, Project Discovery Documents, Project Debriefs, hiring of new Project Coordinators etc. These are by no means the only processes that contribute to team and project progress, but I do find them to be the skeletal, basic ones that have an important role.
Team Meetings
We’ve recently revamped how we run our team meetings, both their frequency and structure. Before, our SalesForce and Compass* teams would have weekly meetings, but the majority of the teams would meet ad hoc or would often be scheduled for when something went very, very wrong with a system or platform. This includes our management team — it’s very easy to overlook the management as a team in itself, but I would say it’s extremely important to recognize this.
We started small with sprint meetings, our three-people API team being the guinea pig. Our aim was to reduce the noise and see whether narrowing task scopes would improve task completion and developer morale. We worked through this in partnership with the developers as it didn’t make sense to push out a process change and force it on the teams without their input — the changes we wanted to succeed with would only be successful if collaborated with the developers, rather than the management level. You can’t force change, it has to be gradual.
This was definitely an adjustment for our teams and their feedback was key in giving us the tools and confidence to continue working on this. Eventually, we rolled sprints out across all of our teams. As a result, we’ve implemented a few changes:
- We restructured our team Trello boards to have the same names for the columns so that no matter what team board you’re in, the operating principles are the same;
- Our sprints were set at 2-weeks across all of the teams;
- The number of tasks is roughly the same per developer;
- As the departmental Project Coordinator I am responsible for following up with stakeholders on any QA/Review items or Blocked cards, as well as taking notes throughout the sprint and posting them in Trello;
- The Done columns have been renamed to reflect the dates of the sprint and developers would shuffle their completed cards into the according columns (as Trello currently doesn’t have reporting capabilities, and their custom fields aren’t available in their API yet, it’s difficult to track and report card completion progress — so we have a workaround for the time being).
So far, so good. This has been working fairly well for our teams. Our sprints, and how we work, have been successful in keeping the developers focused on the task at hand. In addition to this, it gives them enough flexibility to recognize the differences between how teams (as well as other developers in the department) work, while still managing to stay consistent across them. I think one of the biggest things these sprints have done is break communication barriers and silos within the team and between different teams.
As we’ve gotten fairly efficient with our sprints and how they run, we’re now at a point where we’re looking to take it to the next level and improve/fine-tune our process even more. For example, we’re experimenting with using a point system rather than time for estimating a task. Our API team is yet again the prime testing team for this. But more on this at another time.
Oh, and our management team is on 2-week sprint meetings also. Definitely a win in my books.
*Compass is our internal reservations system, built in-house. It’s where trips are booked, created, inventory is kept, etc. fun stuff like that.
Requesting Projects
As mentioned in the previous post, the notion of Freedom (yup, capital “F”) is kinda important around here, and we’re big on being approachable to the business. We want to stimulate a cooperative environment between our Technology department and the rest of the business when it comes to projects. Ultimately, our aim is to operate as a team rather than feel like we’re in a constant tug-of-war.
As part of the “Freedom” methodology, we also include approachability of the department — meaning that we want to ensure that our business feels comfortable enough to approach anyone in the department to discuss projects or any feature requests. This worked for a while I would say, but then we grew in size. Then we kept growing as a company, ultimately reaching a point where having a flood of requests coming to anyone and everyone made things a bit confusing. It was hard to understand priorities, push projects through to completion, and have enough resources to cover priority projects and tasks.
So we figured we’d streamline this a little bit.
We first started differentiating between the types of requests, and came up with the general categories of “feature requests” and “projects”. We looked at feature requests (or “enhancements”) as tasks that won’t take more than one sprint, so 2 weeks, to complete. They often include enhancements or tweaks of existing platforms and systems. Projects, on the other hand, are anything that goes over that outlined period, is on a global scale and impacts a big number of users (e.g. transitioning over to a new budgeting system, or building a platform for trip check in for our travelers and CEOs). These are also items for which we would always use a Project Coordinator.
Projects still get communicated to us “verbally” and are dictated by the business — that is our company owner would communicate this to our VP as a priority for the business. Then the team managers/directors would communicate these to their teams and assign resources. Feature requests, we’re still working on. We have reached a good point where we have a request form in SalesForce that we are going to start asking users to fill out. We’ve integrated it with Trello, so when it’s submitted it will automatically create a Trello card with the key details on the Managers’ Trello board and will subsequently be slotted accordingly — either scheduled for upcoming sprints or in a catch-all request column (we have these, and we will continue to have them due to the nature of our business. Remember, we’re very interrupt-driven).
This nice little form allows us to gather a base set of information that a developer would need to start working on a task. It also reduces the number of meetings we have; meetings can be extremely beneficial, but like most things — when you overdo it, it just starts being counterproductive. This form also helps our requesters get a better sense of our business and how we operate. They are asked to invest time and elaborate on their request, getting to The Why behind their ask. We can have an entire post on the notion of The Why, but for now, we’re leaving it as is.
Project Docs
Our project documentation we are currently keeping basic — we have the Project Discovery Document and the Project Debrief.
The Project Discovery Document is a document that outlines the project itself. This includes, but is not limited to: estimated completion date, the goals of the project, stakeholders, tasks, phases (if applicable), ripple effects, necessary training, etc. The document is usually filled out by the team director with input from the project stakeholders.
The Project Debrief is quite new and used as a high-level overview of the project that has been completed. What the debrief covers is the main outcomes, pain points and learning opportunities identified while working on the project. Our aim is to keep it somewhat short, no more than 3–5 pages. The idea behind this is that when you would go back to a document for a quick reference on what happened, “quick reference” doesn’t mean reading through 10 pages of material.
We have recently started using the Google Suite quite heavily across the department, and this is where we store all of our templates for project documents as well the filled out documents themselves.
In conclusion of this post — we’re getting there. Bit by bit, step by step, we’re starting to build out behaviors and habits that work for our environment and our customers. It’s a continuous wait-no-maybe-we-reevaluate-this-then-tweak-it approach as we go day to day, and it’s in conjunction with working with a whole business whose core beliefs center about being limitless and making anything possible. Even through project management, we are aiming to enhance every user experience, interaction with the brand that much better, that much more powerful, that more life changing.
Next up? We’re talking about what we’re in the midst of right now — hiring a new Project Coordinator for the team. Yup. We’re growing in this organized, charming, continuously-challenging chaos we call G.
Keep following us on Medium and Twitter for more snippets of the Tech world according to G!
Want to work at G Adventures? Join our growing team and travel the world! Check out all our jobs and apply today.
