As a PM at a digital agency, I’ve seen a big shift in the projects I’ve been managing recently. They’ve gone from a wide range of applications to predominantly mobile builds. In the last two months, I’ve worked on an Android build, an iPad app and two iOS proof of concepts.
This transition has pushed my comfort zone and made me rethink my approach to process. It’s made me change how, when I can’t ‘do what I’ve always done,’ to strike a balance between keeping control and giving freedom to the team.
Just before Christmas 2015, I learned that we had won a contract to build two prototype iPhone apps. We would have 13 days to design and hack together two prototypes for the client who would demo it to key stakeholders during the first week of January.
The project kicked off with a one-day workshop where the four companies involved came together to understand and agree on two proof of concepts from a user need perspective as well as work toward understanding the user flow for both products.
A full-day event with all key stakeholders present enabled us to kick start the project, identify key decision-makers, ask and answer all the ‘stupid and awkward’ questions, align everyone on the project goals, and decide what was in and out of scope. Everyone left the meeting with a clear idea of what we were building. We also formed project principles that we could use as a framework for making decisions, a list of milestones, and deliverables required for each product which would then form a project plan.
What we didn’t have at this stage was a process.
I had one working day between Christmas and the New Year. I created a project plan using TeamGantt, mapping both products and the dependencies between the four companies. I circulated it internally and was greeted with this message from our Managing Director (MD):
This looks great. On the calls we had before Christmas, it was decided that someone from the client would take on overall project management — they’re calling it programme management sometimes. I feel like it’ll be a tough job — coordinating four companies working at breakneck speed.
The best tool you have to manage your project with is your mind.
I felt a mixture of emotions. I was glad that someone else thought my project plan was good but reading that someone else would take over project management gave me a sinking feeling. Perhaps I hadn’t instilled enough confidence in my ability to competently manage this project.
I returned to work after the Christmas break to an empty JIRA board. I had no visible task list, no idea how far through the development we were, or whether we would hit the impending deadline.
My instincts told me we were going to be okay but I had no metrics to prove this. We had a very tight deadline and a lot of pressure sat on our ability to meet it. Brett Harned says...
Brett’s right—collectively our team had years of experience to draw upon. So I focused on what I knew: the client was happy and the team was absolutely competent and reliable. They were producing great work and it was clear that they didn’t need me on that part of the job. At first, I felt redundant but as the project progressed it became apparent to me that my role was to observe, listen, and work with them to fine-tune a new process I wasn’t in control of.
The world is moving so fast these days that the man who says it can’t be done is generally interrupted by someone doing it.
While I worried about how to manage the project, the actual work was getting done. This new role was less task- and more people-focused. I had to be far more strategic, providing and reminding the team of our vision and direction.
Our Technical Director often stresses the fact that projects should run at an appropriate speed: sometimes you’ll need a speedboat, sometimes a container ship. JIRA boards, estimates, acceptance criteria, and granular task lists are useful when you’re working on a large software build but they don’t work on rapid prototyping projects. It takes guts to abandon the tools and processes you’re used to, but sometimes a simple Evernote task will do the job just as well. Not all shortcuts are lazy; some are smart.
My new job was to streamline the process and challenge our standard procedures at each step, questioning what elements would add value and which would increase waste. A core part of any PM’s role is to track progress, but this was difficult on a project where the scope changed by the hour—in fact, it was nearly impossible.
So I found new ways to measure progress, like how frequently we released builds with working features the team could play with. Meanwhile, our weekly calls and face to face meetings allowed us time for unstructured thinking. I became increasingly ‘comfortable’ with a loose agenda, so we used these meetings to run through the app and gather feedback. These meetings provided a safe environment for the team to talk through things: “we don’t know what to work on next,” or “this is going to take too long, I think we should do it like X.” Then, as a team, we would plan the next batch of priorities and set internal milestones to keep the entire project moving.
In the end, we delivered the prototypes on time and everyone involved was happy with the outcome. We built a new process without even realizing it. Here’s what we learned:
Twice daily scrums
Things move quickly, so keep talking.
Bi-weekly longer meetings
These are great for design reviews.
No estimates & blocked time
When the scope is changing fast, estimates on a task level are difficult. Instead, give the approximate rates for a team of one developer, one designer, and one PM working at full tilt for that period of time.
Experienced colleagues
On a rapid prototyping project you need to be able to trust your colleagues to deliver, so make sure you put the right people on the project.
Sit close
Ideally, the project team sits together. Designers and developers pair-programming and making changes on the fly (rather than in Photoshop) is a lot more efficient.
As a PM I’ve learned a few things, but one of the most important is to let go and trust my team. When you focus your energy on providing clear goals and making sure each member of the team knows how to make the biggest impact, you do something amazing: you empower the team to manage themselves.
