Today we are talking with Timothy Quinn, a mobile project manager in Toronto. Timothy is going to talk to us today about project management and the mobile development industry.
Welcome Timothy! Please tell our audience a little about yourself and how you got to where you
are today.
TIMOTHY: About 15 years ago, I joined a company in Toronto called Personus, and they had a strong focus on traditional PMI-based project management, which was something I’d been avoiding for a few years because I was a bit intimidated by all the discordant acronyms. Come on, the PMI really couldn’t squeeze another vowel into PMBOK?
At Personus, I learned a lot of what I know now about waterfall project management, and as much as waterfall tends to be criticized these days (perhaps not unfairly) as stodgy and change-resistant, I still use a fair bit of that old school methodology to pull in the reins on projects where Agile doesn’t do a good enough job of managing risk.
What specific project management best practices are evolving to meet the needs of the mobile development industry?
TIMOTHY: Platform fidelity has always been a challenge in software development, but in mobile, it’s a huge issue: how will a given web or native application perform across the current landscape of mobile devices? It’s a size problem (there are several nearly six billion mobile subscribers in the world now, believe it or not), but it’s also a problem of scatter — unlike desktop browser analytics, which basically drop off a cliff after the top three (Firefox, Chrome, IE), mobile device profiles slope very, very gradually towards the point of irrelevance, which unfortunately means developers need to worry about a much broader swath of capabilities. Project managers are therefore learning to apply much more rigor around planning, analytics analysis, acceptance criteria, estimation, resourcing, testing and long-term support.
A good example is UX — a best practice for architecting desktop web usability has traditionally been to abstract out information flow to the point where the specific browser is irrelevant. In mobile, that’s dangerous — there can be optimum flows for iPhone, or for iPad, or for any number BlackBerry or Android or Windows handsets, or for WAP devices, etc.
How does this impact overall project management effort?
TIMOTHY: Project management during development doesn’t change much, but the overall topology of your project is going to start to look weird. Whereas in traditional software development, a project manager might aspire toward the holy grail of a third the budget dedicated to planning, a third to build and a third to testing, a project manager is going to face a much less linear effort in mobile: planning and testing assume greater importance, and to compensate for elongated timelines, there’s going to be a temptation to run more development tracks in parallel, which obviously increases risk. If you’re using any kind of porting or transcoding technology, that’s going to dirty up the separation between your codebases, so that’ll add some complexity as well.
What tried-and-true processes have you found work equally well in mobile as with other software delivery platforms?
TIMOTHY: Bottom-up estimation, daily status tracking and reporting, defect management, post-mortem management, variance analysis — most of those traditional technical project management processes are extremely useful regardless of the end delivery platform. And yet, perhaps because these are very familiar time-worn processes, they seem to get forgotten on projects where the emphasis is on innovation or speed to market. Your average senior executive might not blink at the prospect of building on top of an unfamiliar third-party publishing platform, but suggest an extra twenty-four hours to mitigate risk during estimation, and all of a sudden, you’re the Vogon.
Reducing overhead during development is one thing. But why would companies avoid committing hours to post-deployment processes?
TIMOTHY: There’s the money: a project that’s more than 10% or 20% over-budget is under pressure to stop hemorrhaging dollars as soon as possible. Of course, those are exactly the sorts of projects that should be fixed in a post-mortem. Then there’s the sales pipeline: a project which delivers late may be preventing another project from ramping up, so again, there’s tremendous pressure to unclog the pipe, free up resources and focus, and emotionally limit the impact of one bad project on others.
Finally, I think there’s a bit of Darwinism at play: successful companies aren’t run by navel-gazers; the most empowered senior managers are those which circumstance selects for their ability to look forward, not back. Introspection and analysis are counterintuitive when the market seems to reward gut instinct and perseverance.
Unfortunately, speed and muscle only work in your favor if you’re travelling in the right direction. Put a few sharp turns along your route, add a couple unpredictable competitors, and now speed is a disadvantage.
Yes, just like in Rollerball.
So post-mortems should ideally act as a form of course correction within a company.
TIMOTHY: Yes, absolutely. A good project manager will want to understand why a project went awry and, by documenting specific points of failure, mitigate the risk of those problems recurring. If you don’t document your failures, or if you fail to turn those observations into actionable steps for improvement, you’re going to make the same mistakes again and again.
To run a post-mortem, I’ve generally used whatever tool-set was on hand: Google Docs, Basecamp, shared documents on a file server. None of these really assist in the post-mortem process, however, which is why I built Project Slicer.
Can you talk about how your post-mortem app “slices” projects?
TIMOTHY: It’s a web application like Basecamp or Trello or Reqall; if you’ve used any of those sorts of tools, Project Slicer will be pretty easy to pick up and start using immediately.
You can sign up and create a Project Management Office (PMO), then add projects and team members. As you create projects, you also add quantitative data (as estimated hours versus actual hours) and qualitative data (by having the system email team members for feedback). The system aggregates health and quality data into a dashboard which can be sliced by client, project type and project manager.
The more projects you add, the more data you have to analyze and the more likely you are to identify trends which you can address with iterative process improvements.
Looking ahead, how will the mobile ecosystem change for project managers over the next few years?
TIMOTHY: The line between desktop web and mobile web exists today primarily as a marketing convenience; a few years from now, the notion of a “mobile website” will be an anachronism: every website will by definition be a mobile website as more and more people start using mobile devices as a primary access point to the web. Project managers will build mobile interfaces as an inherent part of creating an online experience.
Over the longer term, the notion of the web as an external entity will also disappear — as it is, my kids, who are six and eight, don’t have the same notion as people my age of the web as something one “goes to” or “accesses”; for them, the web is an inherent part of using the iPad or pulling up YouTube clips on my phone. Cellular versus wi-fi is basically battery power versus electricity. This evolution of the online paradigm already has an impact on how we envision and build mobile applications — we’re now constantly thinking about both the connected and the disconnected experience — and will ultimately transform the overall online experience into a myriad of design states (cellular, broadband, cached, roaming). When my kids hear me talk about the Internet years from now, it’s probably going to sound a lot like someone from my grandparents’ generation talking about horseless buggies.
Timothy, what excites you about the work you do?
TIMOTHY: I think our children’s children are going to look at the turn of the twenty-first century the way we’ve come to look back on the late eighteenth century, as the beginning of an era of very rapid sociotechnological change, so that’s a pretty exciting thing.
And one last question, if you could travel anywhere in the world, where would you go and why?
TIMOTHY: I’d love to visit Nairobi and check out one of those $80 IDEOS phones. There are some pretty inspiring things being done with mobile in the developing world these days.
Timothy Quinn’s bio:
Tim is a hands-on technical project manager with 15 years of experience in interactive media. He has taught at CUNY and NYU, and is the author of the book Octopus Intelligence as well as a project management blog called Process Refactored. Follow him on Twitter at @timothyquinn.
