Most people these days wouldn’t fly without an altimeter, speedometer, radar, or aircraft controllers. Working on a project without a competent project manager falls into the same vein.
Project managers are not schedule jockeys — the kind of people that parachute in once a week, ask for task statuses, beat the team up about slippage, and leave. I’ve worked with these types of clowns in the past — we usually only got about half an hour of terror from them a week unless things had really gone south in their absence.
Project managers are also not the people deciding the features and direction for a project. They are the people that make sure that the product owner’s goals get met efficiently and provide visibility into the project’s execution so that the product owners can make informed decisions.
Project management was not something I naturally gravitated to, but a set of guidelines I eventually had to pick up in order to survive as a business owner.
To clarify where I came from, there was a point, about ten years ago, where we’d taken on a project for a large amount of cash up front, and the project had run on for several months. At some point, I looked at one of my business partners and said “are we still working off the money they paid us to do this work, or are we paying for it ourselves now?”
No one knew. We eventually got out a calendar and worked it out and found out that we had about 3 weeks left before we’d spent it all on labor. Not knowing that felt stupid to me, and I don’t like it when we’re doing stupid things, so I made a point about figuring out when each project would run out of its budget from then on.
Life on the Mean Streets
Early on, almost all of our engagements were fixed cost, fixed scope, and fixed timeline. There were a lot of painful lessons learned along the way, but we survived. After years of work and countless projects, we adapted and got better and better at our craft. Project management was a huge part of that evolution.
Survival meant knowing exactly where we were in the project, what was left, and when to shift our focus to the next thing. It meant knowing how to set priorities, and it meant being able to see the big picture. It meant thinking both strategically and tactically.
These are the skills I used to keep my company alive. These are the skills I require the PMs at our company to master. I’m not a certified scrum master. I’m someone who needed to get on top of things quickly or lose my business, and my outlook on project management borrows liberally wherever I pick up something that I can see is useful, and gets better results than 90% of the agile projects out there.
In doing research for this article, I also realized that much of my philosophy here was guided by my previous education and experience in space systems engineering — but I assure you, this isn’t rocket science.
Ultimately, these experiences draw on lessons learned in the field, experience in systems engineering, and contemporary software project management methodologies and best practices.
I think that a quick recap of the Agile Manifesto here is appropriate. This was drafted by experienced people in software and the primary tenets apply here very strongly.
“We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
The primary reason I am sharing the practices I use is that they got us results. Results that were superior to anything I’ve seen in the industry, and that led to tremendous wins for our team.
It is way too easy to confuse knowing a methodology with being skilled, and that’s part of why I wrote this article. As the manifesto itself says (“Individuals and interactions over processes and tools”).
Having a common process is a good way to teach group tasking and communication skills, set common expectations for how things will work, and (potentially) keep track of progress. The Agile methodology is a well-thought out codification of many good project management practices, which is why we use them at Black Pixel.
But being a certified scrum master does not make you an effective project manager any more than getting your driver’s license will make you Mario Andretti. Likewise, no two-day course is going to teach you how to think critically, assess risk, build an app and test it or understand the sheer weight of the financial responsibility you have been shouldered with.
I can get admittedly angry about this. I have seen huge clients put people ill-equipped to lead in decision making positions based on this training and some questionable previous experience, and have seen the damage it caused. Literally millions of dollars in rework, missed deadlines, and inefficiency. Some clients survived this and many, emphatically did not.
That said, we embrace agile methodologies, and our PMs use them well.
This article dives into the additional things that we’ve found be important in project management.
The steps outlined here are part of what put Black Pixel on the map in the first place. We have a reputation for great engineering but our logistical capability has allowed us to ship some amazing apps on crazy timelines — and no one besides my business partner and I (who were managing the project) had to put in any time on weekends to do it.
Step One: Plan Your Campaign
You’ve got the estimates, you know the team sizing. Use a gantt chart to plot out the initial campaign map, including dependencies and opportunities for parallelism in broad brush strokes. It will give you a sense of the minimum amount of time it should take to finish the project and how the overall major tasks should get rolled out.
Make sure you include time at the end of the project (ideally a couple of weeks) for polish. This is when the team will double down on bug fixes, fine tuning, and performance optimization.
The gantt chart is an artifact that will also give you an at-a-glance sense of how you’re tracking to your schedule, based on what you know about the app and your backlog.
Identify risks and try to minimize them by scheduling the riskier elements of the project as early as humanely possible without resulting in rework.
Side note: There is no bigger risk than building a mobile app against a web service that is under construction. This is like trying to build a house on a plot where another team keeps coming in and tearing up the foundation again. Random changes to the web service, or regressions, will catastrophically consume your budget. If you’re working for a client, set expectations and track every issue that causes rework or blocks the team (including things like losing half a day to tracking down a bug that turned out to be caused by an unplanned change to the web service).
I typically update the chart as major tasks are completed, but almost completely move from the gantt chart to a more conventional issues tracker (usually JIRA for clients, FogBugz for our own internal projects) organically as the project gets moving. We use auto-leveling in the gantt chart to automatically update the milestone expected dates as time moves on.
The gannt chart will give you a strong sense of urgency around what needs to be done right now to ensure that there’s time available for all the other work your team will need to do further down the road.
Use your issue tracker, and the original plan, to track your progress and detect churn.
Have your team layout the navigation hierarchy of your app, with placeholder view controllers and views, ideally using static images from the design comps for each screen that hasn’t been touched yet.
This serves two purposes — for one, your product owner can get a feel for the app sizing and navigation immediately, which can be a big help.
Probably more important is that laying out the primary screens of the app up front means that no one is blocked when they’re ready to start fleshing out one of the views. They can replace the image with actual content and start building out the view right away.
Devs: you know how you spot something you need to fix every time you go off into some area of the app you’re working on, but keep forgetting it? OPEN A TICKET ON IT WHERE YOUR TEAM CAN SEE IT, EVEN IF IT IS BRIEF.
If there isn’t a ticket for it, it doesn’t exist
The rest of your team is likely unaware of the issue — this makes it something that anyone can see and offer to help you out on if they need something else to do for a bit. They can take it off of your plate for you, which is nice. Also, you clearly suck at remembering this stuff, so getting it captured will help you if no one else.
Some people grouse about incomplete tickets — that just means that they saw it (good job!) and you need to go back and flesh out the details. Don’t let the complaints stop you from putting in just enough information to capture the issue. Come back with the details later if you’re in a hurry and can’t write it out fully in the moment.
Tickets details need to include estimates of expected and actual duration. This does not have to be arduous, but it’s very useful information. Once people get into the habit it adds a few seconds to ticket creation and editing. Mature engineers are not afraid to provide estimates.
If you’re in a hurry and it doesn’t seem like a huge task, give it an estimated duration of a day and you’ll look like a hero when you finish within an hour.
This is the biggie and it’s bit me in the ass more times that I’d care to admit.
Everything can look great and still be going to hell, even with reporting, demos, and a great burn down chart. Even the best developers and testers can succumb to hyperfocus, leading to an overall lack of completeness, churn, and distorted view of the big picture. Metrics are great, but does the app work the way it is supposed to at this point in the project?
The project manager should be capable of building and running the product from source (not the latest build!) a few times a week. The goal is to try some basic usage and have direct personal experience with what is and is not working. This is hugely empowering and shouldn’t take more than five hours a week of your time.
I have had numerous reports from people of great progress, and then sat down and promptly reduced the app to shreds by putting it through its basic paces. The feedback got the issues taken care of promptly and helped get us closer to convergence.
Sitting down and just using the app your team is working on a few times a week can give you a ton of vital, direct experience and is probably one of the most valuable things you can do for them. When the ticket load seems to be well managed, run through the app and look at the current state of it and keep an eye out for regressions. Write down and thing you see and then make sure there’s a ticket for anything you find.
By the way, this is important enough that we started instituting principals reviews for all of the apps we work on earlier this year. Once a week, some subset of the company leadership will sit down with a project manager and the lead dev, and a member of the test team and personally try to pound the crap out of the apps ourselves and see if we find anything someone else may have missed. It’s useful for everyone.
Tips: look for defects: slow loading, loading every time something is viewed instead of caching, Abrupt transitions, slow scrolling, etc.
There’s nothing that says you have to do this alone. I like to buddy up with another manager once in awhile, working together to test and capture issues for an hour or so, then switching gears go help them out with what they are working on.
Also, draft your own basic test plan if there isn’t one and share it with the team. The point here is consistency and efficiency. If you’re doing an ad hoc test every time you may spot a bug without a clear sense of what the steps were to reproduce it, or may forget a step and realize it later and have to start all over again.
Start by just writing down notes about what you’re doing so you have steps to reproduce. Then start optimizing it as you go through it over the next few weeks (kaizen).
Get Dynamic Data As Quickly As Possible
I’ve seen a slew of refresh issues crop up when views were laid out with mock, static data. If you go a long time without getting live, changing data you may find a slew of issues around stale data, cell reuse, etc. Ideally the data will be available before work starts on the views in question.
Redirect People When You Need To
Most devs can get extremely focused on the current piece of the app they are working on and can burn through a large chunk of the schedule fine tuning the part they are currently working on.
If you’ve laid out the project plan you should be able to tell if they’re cutting into the time allocated for working on another part of the app. Have them get to a good stopping point as soon as possible and switch to working on the next feature or view. You’ve scheduled time for polish, performance, and bug fixes, so see how high of a priority the original issues are by the time you’ve hit the polish stage and see if it still warrants the additional attention or not.
You Are The Coach
Some people may resent having sprints laid out explicitly, and being told when and what to work on, but what you are doing is running interference for them — setting up targets for them to take down with maximum efficiency. This is a support role, you are not trying to beat down the morale of the team.
There’s no problem with people picking which tickets they’ll work on in a sprint, provided the priorities and back log are managed well. But there are going to be times that you’re going to have to call the shots on what gets done, by who, and when.
Someone doing hands-on project management isn’t micromanaging any more than a professional soccer coach is when they tell members of their team to make certain plays together or switches out one player for another.
Very few people would argue that the direction of a coach is unwelcome. A great coach can have an incredible impact on the success of a team, and a poor one can be devastating. The same is definitely true in software.
This is attainable
One thing that I want to point out about all of this is that you don’t have to be a software engineer, or a rocket scientist, to be able to do these things. These things can be taught. People like Matt Drance and Chris Clark both taught me a lot when I worked with them, and many of those teachings have been absorbed into what we do today. Showing people what to look out for when you come across it goes a long way.