1) Understand your personal work and productivity style
2) Understand that others also have a style, and tailor project management to the team.
3) Understand the software process (waterfall & agile)
4) Understand bug triage.
1) Whiteboard markers.
2) A chart of your own day.
I wanted to open this class with some more personal aspects of how to get things done, and get software built. Hat tip to Steven Benario, who helped me brainstorm some of these exercises.
The reason I wanted to start here is that people often think PM is just trying to “keep Engineering on schedule.” This is usually not the case – getting a team to run well is far more complicated.
On top of that, I find that PMs often say they want to manage other peoples schedules, but don’t have a good sense of their own time. I wanted to build empathy and for why project management and scheduling are hardd and important.
Understanding Your Own Time – One Hour
I opened this class by explaining my day. “Today, I’ve been super productive. I woke up early, prepped some cases before class, went to my classes, ordered lunch delivered to give me more time to work, came out here, read some more cases, and now I’m teaching!” It sounded good.
I proceeded to show them an actual snapshot of my day from 7:30 – 5pm. This wasn’t so embarrassing to share with students, but is a bit worse to have on the internet (at least it’s honest!)
7:25: Alarm Goes Off
7:34: Get up
7:34 – 7:40: Get Coffee, Feed Cat, Sit at Desk, Email
7:40 – 8:10: Read LCA Case, Read FIN Case, Twitter, Facebook, Distractions
8:10 – 8:20: Get Dressed, Take out Recycling
8:20-8:40: Walk to HBS
8:40-9:10: Get More Coffee, Get Water, Answer Email
9:10 – 10:30: Class
10:30 – 10:50: Awkwardly Stare at Email, Answer Peggy, Answer Cole
10:50 – 12:10: Class
12:10 – 12:20: Awkwardly Stare at Email
12:20 – 12:30: Move for Meeting
12:30 – 1:04: Lunch Roulette Meeting
1:04 – 1:30: Walk Home, have Postmates bring lunch
1:30 -2:15: Eat lunch, chat, email, shower
2:15 – 2:27: Chat
2:27 – 3:28: Get coffee, walk to Zipcar, drive back to house, get cables, drive to Olin
3:28 – 4:00: Chat, useless things
4:00 – 4:50: Read LCA Case, Skim TEM Case, Email bio to Caitlin, read this article: http://pi.co/jenna-wortham-new-york-times-writer/
4:50 – 5:05: Write this document, inefficiently
Even though it sounded productive, there was a lot of wasted time in my day. I sorted my time into three groups: productive, necessary, and unproductive. Necessary means things like eating, my walk to school, and other required activities.
Conservatively, I wasted 33% of yesterday (about 177 minutes). That includes staring at email while not answering it and awkward time between meetings. It’s also the time I try to work and read Twitter at the same time.
I did this not to shame “unproductive” time. I find that I need a certain amount of unproductive time. It’s important to have fun and see friends. The thing that matters to me is that it’s “quality” unproductive time. I’d rather save up an hour to grab coffee with someone, rather than staring at my email for three twenty minute chunks.
It’s good as a PM to have a baseline for how you use your own time. If you think you’re “busy” – you often aren’t.
I had each of the students do the same exercise, for their own Wednesday. We had a range of values: the most productive student only wasted about 12% of her time! The most time wasted was right around my 33%.*
Once we had this baseline, as a group we reflected on “what made today (un)productive?” and what things help us to be productive and unproductive.
Each student shared an item and it helped us to build a framework to consider productivity (my whiteboard plan got kinda messy this time).
- Getting or staying focused: Some people have a hard time getting in the zone to begin with; some people have trouble staying in the zone. Knowing what times you are likely to be “on” and “off” can help with this. For me it’s important to have large uninterrupted periods of time to work in.
- Environment Shifts: Some found these helped, some hurt. For me it’s hit or miss by the particular space, so if a space doesn’t work in the first few minutes, I need to move.
- Teams: Some people work well in groups (actively collaborating), some people work well in groups (individually working nearby each other) and some people work well alone.
A few others that don’t need explanation:
- Micromanaging time / task blocking
- Rolling task list
- Historical task list
- Deadline pressure
Next, we talked more specifically about being accountable on laptop time. Two tools I’ve used are WebTimer and RescueTime. Both are tools that help you track how you spend time on my computer. I shared some of my own data (based on 238 days while I was working – not at HBS). This is work + personal time – the large purple 21% is “other.”
This doesn’t bother me much – I’m one of the few people who uses Twitter (web) more than mobile. Since I haven’t seen how this changed lately, I turned Webtimer back on and I’ll report back. I also showed how I use Trello as a personal tool to manage tasks and fill in gaps in my time. I also gave an example of using Trello in the group context to start off the discussion below.
Group Time – 45 Minutes
Next, I wanted to apply this to the projects that students were doing in class.
After spending time reflecting on how hard it is to get yourself to work, it’s easier to have empathy for others’ work styles. Everyone has all the idiosyncrasies that students learned about themselves in the first part.
I mentioned one team in particular that I worked with for a class, and our own styles. I’m hoping my memory holds here (this project was back in 2008, and I enjoyed it quite a bit).
Me: When I’m on, enjoys meetings, likes collaborating. When I’m off, I’m sarcastic and hard to work with.
R: Also sarcastic, enjoyed group parts of the meeting. Less likely to do tasks outside of meetings.
A: Hated meetings, wanted to work on specific tasks, with headphones on.
G: Didn’t like the class, didn’t want to be there, made stuff out of blue foam.
L: Most motivated to learn, wanted everyone engaged, enjoyed meetings.
The result was that this group usually divided tasks according to those preferences. The person who wanted to do graphics did that, the foam did that, and the other three of us did more of the “group stuff.”
It’s important to keep these things in mind if you’re coordinating to move towards a goal. I wanted students to reflect on their team members and why they might be participating (or not). Things that seem to be “schedule” problems sometimes turn out to be personal/motivation problems.
(In the classroom I shared a few more work/personal examples of this).
I also wanted to give a bit more of a framework than “think about your group.” I drew on the the board from “now” (March) to Expo (May) which is when most student projects will be ending.
To tie it back to how people build in the real world, one of my recommendations was based on the Amazon Press Release Strategy.
Amazon has Product Managers write a “press release” of the Product before the begin spec’ing or working on it. I tried to turn this into the Olin equivalent of “think about what you’d want to present at Expo” before you start your class project.
My other recommendation was to think about the process of the two week timeframe. How often would you meet? How would people be accountable for their work?
There’s a note at the bottom, but I wish I would have taken some time here to refresh and expand on the difference between Waterfall and Agile.
By the time we’d finished discussing, we opted to move into Bug Triage rather than spend the time on working on projects in class. I’m hoping the students will do that another time.
Bugs & Bug Triage – 30 minutes
This section was pretty standard. My main goal here was just to get students familiar with some basic software concepts around bugs. Bugs are common knowledge for most PMs, so I’ll just share the skeleton. If you’re trying to learn, there are lots of other good resources about this.
First, we talked about the timeline of the process as the software in waterfall. Notably: Feature Complete, Code Complete, “Bug Bar” and ZBB. This might not be common in startups, this definitely still happens at places, and it’s something I’ve run into during my work.
Then we talked about opening a bug. That included the idea of writing “expected vs. actual behavior” with a description, as well as the difference between Severity (how bad) and Priority (how obvious/often) and the rankings from 1-3 for each.
Finally, we talked about the decisions a PM makes about how to resolve a bug: By Design, Dupe, Won’t Repro, Won’t Fix, and assigning to a Developer (for discussion).
For me, the most amusing moment of the class was when a student realized for the first time that all software has bugs.
1) I forget how different college and real life are. The students anchored much more harshly on “productive/unproductive” than I did. I fielded many questions along the lines of “is eating lunch for half an hour unproductive because I could’ve done it in 10 minutes?” In retrospect I might let them make their own categories for how to group things, or call necessary “reasonable life management.”
If I was going to rank when I’ve been the busiest it’d be: Olin, High School, HBS, Work.
2) I really flubbed in the middle of this lesson. I meant to go from group dynamics into Waterfall vs. Agile. Luckily we’ve touched on it in other classes, but if I did it again, I’d definitely wedge that in between there before moving on to triage.
3) To save you some time, it’s hard to come up with non-software bug examples. It’s just so primarily software based.