What Successful Project Management Means To Me

If I were to boil down the cause into one thing (which I can’t, but if I were forced to try), it’s the disconnect between developers and clients that aren’t developers. If you ask a home developer to estimate the cost of building your home, they can come up with very reliable estimates: cost of materials, labor, and margin of error. This is how clients presume software estimates work as well. The reality is that the first release of software I show to a non-technical client can lead to a pandora’s box of change requests, because clients often don’t know what they want until they see a semblance of the real thing. Unfortunately for developers, the market expects an estimate, and it expects developers to stick to them.

So I consider it my job as project manager is to accept this market reality, understand the extreme difficulty of software estimates, and still manage to keep both developers and clients happy at the end of the day. Yup, project managers are the mediators of the software development world, and my post today will be about strategic and tactical ways that I try to make both sides happy.

Budgeting

When I share app development costs with clients, I always present a lower and upper limit, while emphasizing (often repeatedly) that this is the estimate, not the quote. The quote is an entirely different equation, starting with whether we have clear specs and/or UI mockups off the bat. If we do, then we take the average of the lower and upper limit, put together a fixed price quote, add in 25% of dev time for QA and stabilization, add in another 25% for margin of error, offer up a timeline, freeze the specs (no change requests!), and generally we’re able to either meet or beat this.

If we don’t have specs and/or UI mockups, we add in a phase 0 to come up with them collaboratively with the client. As you can imagine, nearly every client balks at this initially, and getting them past the mental hurdle is one of my most consistently difficult challenges as a project manager. A lot of clients have to take an end-to-end bid to their budgeting person before they get a cent. My job is to figure out how to reconcile this.

First, I build goodwill and good faith by saying they don’t have to hire us for the build itself if they don’t want to. This shows the client we really need this to start building. If end-to-end estimates are still required, then we use the upper limit of our estimates and we say that we reserve the right to change estimates and will almost certainly do so after phase 0. Developers will recognize this as a core part of Agile development, so what I’m essentially doing here is moving the proposal closer to Agile (which is basically common sense in this situation), without making clients feel like we’re just figuring things out as we go. I believe presenting the Agile Manifesto to clients upfront is a surefire way to lose non-tech-savvy leads.

Using this balanced approach, I’ve managed to move clients who were fixed-price-or-bust types to allow a phase 0 with tentative estimates and post-iteration flexibility.

Communication

By communication, I’m really referring to two things: owning my weaknesses and overcommunicating.

1) Owning my weaknesses:

If you’ve ever hired developers before, the vast majority will sound like they know how to do everything involving 0s and 1s. It’s not really their fault: the market expects that hire-ability as a developer now means full-stack. But full-stack never means you’re an expert in everything.

I believe that most small-to-medium shops like mine have their strengths and they should focus on them. I articulate to clients that our developers are engineers in the truest sense — they will write robust, clean, scalable code, and I don’t ask them to touch design beyond responsiveness which every developer should do. If you want design, you’re going to have to hire my excellent designers. Similarly, if there’s a language we don’t do or an industry I don’t know very well, no claims are made otherwise.

To make up for any gaps in knowledge, I add in knowledge transfer time to the timelines without adding in cost. I’m not talking about time to get good at something, but certainly spending 1–2 weeks to learn about the landscape of healthcare interoperability, or to get down the syntax of React Native is something our team does, and we all willingly do it because the personal ROI is worth it. Lying that I’m good at something that I’m not good at means that clients will expect me to be as fast at new things as the things I’m good at, and I’ll be penalized for being slow. Taking on the knowledge transfer time without billing for it means clients will appreciate how badly I want to learn (which in turn makes me more of a partner than a hired gun), they will appreciate how quickly I can pick up new knowledge in the future, and they’re far more likely to be convinced that my velocity will ramp up significantly once I get past the learning curve.

2) Overcommunicating:

It’s very easy when I’m “the manager” to make decisions in a silo for the sake of efficiency. But almost always, this approach is reckless, even if my development team trusts my abilities to abstract business negotiations from hours they’d rather spending coding. I’ve been caught in the web of rapid-fire back and forths with a client for the sake of kicking off a project, only to have my team catch a red flag in the agreement. Instead, I’ve swung toward the other end of the pendulum: overcommunicate. The developers never like it when I send them rapid-fire exchanges, but they’re ok once I remind them this pushes the pain away quickly upfront, so the project itself can be as painless and unsurprising as possible.

Similarly, I overcommunicate with clients after the project starts. Sometimes daily, sometimes twice a week depending on the clients’ availability, but never less. Even if we’re building everything to spec and on schedule and have no questions, keeping the client in the loop and seeing every little morsel of progress on Trello helps them feel better about the process (they’re not gonna look at your github, sorry), and allows us to catch misaligned interpretations and expectations as early as possible. Lastly, I make sure that after every iteration (usually 2 weeks), I ask the client if they’re happy.

Ownership

Ownership means owning the product like it’s my own startup or enterprise. I’m aware that many project managers may consider this outside of optimal project management, as caring about a product beyond the given specs may cost me efficiency. The reasons why I decided to take this approach are that clients love it as a differentiator, and it allows me to pre-empt some expensive mistakes.

For example, let’s say I’m being asked to work on a project involving HIPAA. The client knows about HIPAA, and is using a HIPAA-compliant solution to download health data and isn’t worried about spec-ing out additional measures. As a project manager, I might take this and run with it, since no other caveats were specified. Instead, what I actually would do is make sure there are no user inputs of sensitive data that might get stored. Bringing this question up raises my value to the client from hired gun to partner and eliminates the possibility of a huge change request which would screw up our estimates in a massive way. This goes the other way as well: if I see a real opportunity to shorten a scope, such as using an open-source solution instead of building a custom one, I bring it up. Discussing all the gotchas and options upfront prevents a client from bringing up a huge pivot in the middle of a project which makes them unhappy even if they’re the one that thought of it, and also prevents unhappy developers that wasted time coding something that won’t be used.

Trust

I’ve gotten clients at large hospital systems to work with me mostly on the basis of trust. When I’m talking about trust, I’m talking more about the person than the skillset. Realize that most clients are hiring out a skillset that they know nothing to very little about. Mostly they’re hiring based on the person they’re in contact with the most, which is likely the project manager.

Staying accountable to my word is a tenet of my life as a whole, but in this case, I’m talking about meeting all of my promises. The reason this is such a serious issue is that there’s frequently a disconnect between sales and post-sales. Many people tend to overpromise to close a sale. I try really hard not to do this, but if I slip and end up doing it, I make good on the promise. Whether it’s about getting a UI mockup by a certain date or looking up this tiny modicum of information that I said I would look into, just do it. If a client trusts me, they will also gain trust in my rationale for extending budgets and timelines.

Conclusion

The measure of a successful project manager is the person that knows how to budget, is honest, gets buy-in from everyone, adds the most value to clients, and has the client’s trust. A year from now, a good client won’t remember if a solid prototype took 2 versus 4 months to launch. They’ll remember that during the custom app development process, they enjoyed working with me the human being, got what I said they would get when they would get it, and made their product better than the one they came in with.

Related Articles:

1. On Demand App Development Guide
2. How to hire app developers
3. Agile App Development Guide