Virtual Team Success: Project Management

Culture + Tools + Methodology = Virtual Team Success

Culture + Tools + Methodology = Virtual Team Success

In this continuing series about communications for our business, we are discussing tools and tactics for keeping our minds focused on the right things at the right time. In the first issue, we covered instant communications between ourselves and our partners and customers. Here we talk about some specialized channels of communications.

Communicating Secrets

As much as we love working with Slack, we don’t trust it. In fact, when it comes to secrets, there are only a few communications channels that we do trust, and not too much if we can help it.

Keybase
When it comes to communicating secrets, we are obligated to ensure that it is done securely. We don’t even say passwords over the phone in voice communications. We treat all of our tools with the expectation that they can be hacked. Keybase allows us to be as confident as possible that we will not be hacked or have our messages intercepted. Keybase has been around for several years and have improved their product quite nicely. It is trusted enough so that it can be used as a code repository and a cryptocurrency wallet. We used to use Dropbox. Not good enough.

As part of our jobs, we rotate supporting our customers. That means we need to share passwords between each other. Since we are all virtual, there is no sneakernet. It must go over the wires. We are confident in using Keybase. We use it for passwords and software license codes owned by the company. Also when there are confidential HR materials sent for things like clearances and being bonded for our customers, this is the app.

As a backup, we use Signal which is maturing nicely and now supports voice, video and attachments.

While I’m on the subject of sneakernet, it is important to remember that when your team makes a decision to select a communication tool it is more important that nobody hates it than everybody loves it. Since there is no alternative, the team member who hates using tool X may decide it’s not worth communicating through that channel. In that case everyone loses.

Project & Time Management

Of all the controversies in the world, few get as irritating as how to log the hours you work and expenses your company incurs in a comprehensive and reliable fashion. We are no exception, and we have gone through multiple iterations of drama on this front. We have finally settled on a combination of four tools cleverly integrated together by our own engineers. It is, after all, what we do.

Wrike
The primary communicative face of these four is a tool called Wrike. Wrike provides a central platform for organizing and communicating all of our billable and non-bilable work. We have worked to make it tightly integrated with Harvest and Xero our back-end accounting systems. We also have disciplined ourselves to working tightly with the legal documents & quotes we author in Quotient.

Whenever we have an impromptu meeting in a Slack channel that takes more than a few minutes, whoever called the meeting is responsible for putting a link to the task in Wrike that we spent our time in a meeting for that purpose. So this kind of tracking insures that we don’t have meetings just for the sake of having meetings. Over time we develop an implicit understanding of whether we are communicating in order to think out loud and clarify, brainstorm or bring up an issue. (And of course that is a subject for later in the series). We hate wasting time, and our customers need to know.

We have evolved our configuration of Wrike over time. We have it where we want it. A major improvement in how we do business is matching how we author & negotiate projects with how we manage them. Since we provide professional services to our customers, we have to negotiate a statement of work (SOW). To build our SOWs we use Quotient. It provides a consistent framework for how we present our services to a prospect. As we do, we have customized it specific to our needs. The meat of a statement of work consists of descriptions of what is to be done and how much it will cost. We have, for each costed unit of work, the following details.

- Item
- Description
- Key Activities
- Key Deliverables
- Acceptance Criteria
- Assumptions

Each of the key activities is an identifiable task in Wrike. These tasks roll up to a deliverable like ‘Final Design Document’. These tasks and deliverables match one to one between our SOW and Wrike. When we enter time against a task in Wrike, our integration periodically sweeps the Wrike server to place transactions in Harvest which has its own integrations with Xero, our accounting and billing system. Both are very popular in their own right. When a deliverable is marked complete, we can then bill our customer for that unit of work. This tight integration has a direct impact on our cash flow and everyone on our project teams is keyed into this fact.

Like many companies, we use a hybrid approach to project management. We are required to understand costs and possible cost overruns in a waterfall style. So we will always tie our costs to a hierarchy within a project. We also need to work in an agile context because the unexpected is always a part of the process, and we need to manage that risk. Wrike accommodates this dual footing by allowing flexibility in reporting.

At our weekly status meetings which we call the ‘Big Top’, each of us is required to speak about whether our Wrike tasks are Done or Not Done. We have a conference in Slack, and must share the screen in front of everyone and have some explaining to do. We can report this Kanban style or in a custom template.

After that pass, we use Wrike again to show in a Gantt style the hours we have committed to tasks for the coming week. This is how we stay on schedule and on budget even when we have project team members working thousands of miles apart. We get accountability because we have the right systems that communicate the right signals, and we are disciplined to use them properly. It wasn’t easy, but if we didn’t, we’d be in trouble. It has definitely been worth the journey.

Incident Response

Speaking of trouble tickets, we use PagerDuty to track all of the possible alarms and warnings that we build into our systems. Staff are on call and will be scheduled via PagerDuty. We track incidents there as with any trouble ticket system. However, we make sure that these incidents are integrated into Slack and via email. Most of these alerts are triggered by custom rules built into AWS CloudWatch. But most importantly, we are tying these directly to the Service Level Agreements with our customers. In order to be responsible stewards of our customer’s data, computing assets and functioning application systems, we need to be tied into a process that gets our attention and backs up the promises we make. This is the management side of DevOps.

We use these administrative systems in coordination to manage our time, to discipline our processes and to maintain accountability for the work we do. As a virtual team of creative individuals we keep our personal commitments to use them and structure our communications within our company. These are the kinds of key activities that lots of other companies have considered at length which is why we can use their tools. We think what we’ve learned can help you too.

Coming up in the next guides, we will talk about knowledgebases, runbooks and maintaining archives.