How to “Right-Size” a Project
If you’ve been a project manager for a while, then you know that when a client says, “can you send me a scope of work?” that means, “tell me how long this will take and how much it will cost.” If you’re new to project management, then you have all of this to look forward to in your future. Whether you’re new or rather experienced, here are some pointers to help you along your way.
Share The Burden
Yes, a PM’s job is to keep projects on track and on budget; to manage the teams and help facilitate decisions. However, if you set a scope or a schedule without involving your designer or developer, you might be in for some tension and frustration. It is okay to admit that you are not a designer and you are not a developer, so sizing a coding or branding effort may be outside of your wheelhouse. Lean on your team to help you come up with reasonable expectations. They will thank you for involving them in the process and will be more likely to stay on track because they are accountable for the estimates they provided.
Learn As You Go
After you’ve done this for a while you start to find patterns. You’ll learn about your team’s skills, their ability to deliver and in what timeframe, and you will start to develop some gut instincts about what it takes to work on certain platforms. Unfortunately, these factors vary from team to team and project to project, so I can’t provide you with any magic numbers. What I can do is help you ask the right questions.
- What are you trying to create? List out the goals and expected results.
- How many platforms are you building? List every platform needed (iOS app, Android app, an API to serve the app data, a website, social marketing profiles, press releases, administrative interface for gathering and displaying statistics or user profiles, Google Analytics, Push Notification systems, Email deliverability, etc.) If it’s needed for meet your goals, list it.
- How many full time resources will this take? List everyone needed for the project (project manager, designer(s), mobile developer(s), API developer(s), web developer(s), qa analyst, release manager, content writers, grant writers, SEO specialist, pr team, etc.)
- How long will you need each resource to accomplish the items listed in #1 and #2.
Be Realistic
Where do you need a buffer? The buffer varies depending on the client and the project. Realistically, you provide time for multiple creative iterations, you allow for time for content writing, revision and approval, and you account for the defects that undoubtedly occur during QA. You may provide another bucket of hours (or a range) for unknown roadblocks if you’re innovating on a brand new platform. Finally, if you’ve worked with this client in the past you will know their turn around time on feedback and the number of change orders that arise during a project. These are all things that can affect your scope planning.
People ask me if I’m just padding the hours. The short answer is no. 99% of the time these hours are used and I plan for them because I know what’s needed. I tell the client upfront because it is better to prepare them for that number at the start than to charge them an overage invoice 3 months later. I personally like to provide a range of hours and milestone dates so clients see the high and the low and realize that their participation and timely feedback affects those numbers in a big way. This sort of collaboration provides for a better partnership.
A Real Example
Once, I was asked to size a project for two mobile app platforms. Someone had roughed in a number of 800 hours and I immediately felt sick to my stomach (and said as much by saying I wouldn’t touch that project with a 10ft pole.) When I asked how that number was derived, they doubled to 1600 and asked if that felt more realistic.
It’s true, I’m not a designer or a developer, but I’ve done this long enough. First, I know my team and I advocate for their success every time. I will not knowingly put them on a project that is doomed to fail due to timing or budget. Secondly, I know my platforms and I know what’s needed to build things to achieve certain results. I should have added that to the checklist (sorry!)
Know what you’re selling!
For those who didn’t get this far into reading my blog, oh well. For those that did, thank you!
Okay, back to my point. If you know these two things, then your instincts will tell you if the numbers add up. Trust your gut. Then, ask for time. Assess questions 1-4 above and find the right number. To some 1600 hours feels like a lot. For this specific request, I knew it wasn’t nearly enough. I followed the same steps that I’ve outlined here and when I came back to them, this is what I had:
To accomplish your goals for both an iOS and Android app (handset only because tablet will cost you more in both design and development an qa) you also need an API to serve you data and a release manager to assist with the mobile app stores. Apps of the complexity they were asking for needed 2 months full time development of the API, and at least 4 months per mobile developer. That’s 1600 hours. Without design, without project management, without QA, without any feedback adaptability or iteration period. Do you see where I’m going with this?
The Final Word
It takes time and resources to develop quality applications. Sometimes that final number is really large, but that’s okay because that’s when the conversation really begins. Maybe they know what they want and they are willing to make it happen or maybe you can help them make it happen by giving them everything they need to raise the funds. Work with them to reduce the scope (maybe we’re only looking at one platform) if their budget will not allow for the grandiose goals. There are a lot of things that can happen once a project has been right sized.
I personally am a big fan of being transparent. I will tell you exactly how I got my numbers, but you have to understand that I won’t cut corners on quality or compromise my team to get the deal. If you’ve been in this business long enough, you’ve been there and done that and it never ends well.
Best of luck as you scope your next project. I hope this peek into my process and my little bits of advice help.