How to De-Risk Your Custom Software Development Project Part III: What Project Manager Profiles Your Team is Better Off Without

Those who know me will tell you that both in my personal and professional life I try to avoid cliches and truisms of all sorts.

As much as I’d like to think my lack of tolerance for overused phrases or opinions is a result of my taking the moral high ground or at least a rebellious nature (I’ve always wanted to have one of those!), the truth is I simply don’t have the patience for something that’s been said and relayed a thousand times over. So believe me that it doesn’t come easy when I say this: picking the right people for your team is hard. I know, right? It sounds like recruitment 101 but it took me several years and several misguided hires (and several spot-on picks as well) to come to this illuminating realization.

People that interview with FM for the positions of project manager or assistant project manager often come from different backgrounds and with a variety of skills and professional experience. The candidates that make it through the recruitment cycle usually share certain characteristics that always augur well for new PMs such as analytical mind, effective communication skills and the drive to get things done. Truth be told, it’s not all that difficult to come up with a list of checkboxes that a good PM candidate should check off - after all, every job posting out there specifies exactly the expected requirements a person needs to meet to qualify for the position. We (those involved in recruitment) are often so mesmerized with what we want the candidate to be that we rarely give much thought and screen for all the “hell no’s”. It is maybe a few weeks or even months after the unfortunate fellow’s been brought on our team that we scratch our head and wonder how on earth did we not see he or she were in fact a terrible fit.

Here are five things that should tip off that someone is not necessarily a good candidate profile for a project management position in software development.

They think they don’t need to understand software.

I’m a firm believer that when it comes to IT project management smarts and ambition can sometimes outweigh a technical degree. What is more, instead of being a liability, the lack of computer engineering background can actually become an asset in an IT consulting company - after all, some of our clients and project stakeholders might not be tech junkies following Stack Overflow but average technology users, smartphone holders and Netflix watchers, who happen to partner with us on a software development project. They need and welcome the opportunity to talk to someone who can explain in a comprehensible way how the lines of code translate to UI input validation, API calls and server error handling. To be able to do just that but also to efficiently coordinate the work of developers, testers and designers, project manager absolutely must have a good understanding on how software works and how it’s designed and how it’s built. If all the PM wants to do is schedule tasks and draw timelines, they’ll probably do better in another industry (or profession).

They think that once they understand software, the rest is easy peasy.

Wrong - as surprising as it may sound, it’s not the “software” that is the most difficult in software development management, it’s the management (or people management, to be specific) that will give PM a pause time after time again. We often refer to project management as process management, forgetting that those are real people that write code, prepare mockups, and report bugs - people who come from different backgrounds, have different communication styles, who sometimes get along like a house on fire or sometimes don’t really like each other all that much. And now all those people are sitting together and are expected to collaborate seamlessly. Even the best of well-knit teams will hit an occasional low when the stakes are high and things don’t seem to be going according to plan. It falls on the project manager to tune into the team’s morale, help resolve conflict, facilitate trust and communication culture in which it is ok to disagree with one another as long as everyone plugs into steadily working towards the common goal. Someone who doesn’t have this sort of sensitivity or who isn’t capable of taking a deep breath and keeping their cool (when all they really feel like doing is punching someone in their face) is not a good material for a PM.

They mistake managing people with bossing them around.

For some individuals, the word “manager” in their job title works like a magic spell - they feel they have been granted power over those poor souls who’d be lost without having someone tell them what to do, when and how to do it. That’s probably the worst and the most counter-productive approach any manager can take. Those are probably quite smart people that work on project teams and it’s a pretty dumb thing not to tap into their knowledge and talent by allowing them to drive the project forward with you. Project manager is not anyone’s superior but a facilitator who allows the team to operate like a well oiled machine, so stay clear of eager beavers who cannot wait to be someone’s boss. That being said, on the other end of the bad PM spectrum we have pushovers…

Those who allow themselves to become pushovers.

I know - I just said that the PM needs to be a facilitator and needs to tune in to team’s morale but that doesn’t mean their sole purpose of existence is to please everyone around them. Their primary goal is to get this complex job (aka project) done and as it just happens making sure the team is “healthy” (working together well, clear on priorities, trusting each other) is crucial to accomplishing this goal. But let’s face it - things don’t always go smoothly and sometimes the only thing that will help the team and the project move forward is strong leadership: the ability to push for difficult decisions, to say no and to hold people accountable. In other words, occasionally it is simply necessary for the project manager to put on a bad cop’s hat and at that time he or she is probably not the most popular person with their team or project stakeholders. Being a bad cop is part of the job but it takes a lot of finesse, professional credibility and personal charm to push forward without antagonizing people. A perpetual yes-man or someone who is shy to speak their mind or ask uncomfortable questions simply won’t go very far as a project manager.

They believe one book or methodology has all the answers they need.

Now, this one might cause a frown for some of those who are true believers in one particular PM methodology or framework but I’m going to say it anyway: while it’s super useful to know what the various PM approaches have to offer, for IT consulting companies who provide product development services rather than develop their own product, there’s no one shoe that fits all. We work with all sorts of clients who come to us with all sorts of problems to solve - sometimes it’s the need to rewrite the existing system with a new technology, and sometimes the ask is to reinvent the digital product in a way that will dazzle the users and sideline the competitors. Sometimes it’s about developing an enterprise application that will integrate with a number of third party systems, and sometimes it’s about rapidly building a click-through prototype that will help raise funding for development. Sometimes it’s about fitting in a very specific budget and sometimes it’s doing whatever it takes to demo the system at this trade show in two months time. Don’t get the wrong idea, though - it’s not like we don’t know what we’re doing. Over the years we’ve developed our FM methodology that integrates elements of traditional/linear and agile approaches, and that we’ve successfully applied to the projects we’ve worked on. However, rather than in sets of rules, we believe in principles - and critical thinking, being pragmatic, and taking the most efficient (most value for least effort) course of action are at our core. Someone who indiscriminately wants to adhere to any single methodology they happen to be certified in will never be a good fit for an IT consulting company like FM. They will fare better and be happier somewhere else.

Being that much smarter about what should raise a red flag when screening a prospective project manager doesn’t necessarily make it any easier to come up with the right interview questions that will serve as a “sniff test” - but that is a topic for a whole different blog post.

Read also

Most Read

1 What is a legacy system, and why do companies keep using them?
2 Mobile payments security. What should developers know about it?
3 How to fold QA into every sprint
4 Software development view of healthcare wearables
5 How to quickly add a date dimension to a Pentaho Mondrian OLAP cube
6 Nearby Messages: Sharing Information With The Person That Is Near You
7 Creating a digital product for the healthcare industry?
8 7 reasons to use real time data streaming and Flink for your IoT project
9 How to create an effective Asset Tracking System?
10 Minimum Viable Product (MVP) in software development - what it is and how to define it. Product Owner and Project Manager perspective.

Digital products from concept to launch

We understand that creating a product is a challenging and risky endeavor and believe that having a partner with experience and know-how is a critical first step.

Learn More

The Digital Product Journey

From idea to launch we guide you through the startup experience

Learn More
Path Created with Sketch.

Before you head out, you can download our latest E-book “18 Software Product Killers Every HealthTech Strategist Needs to Know (part 1)”

Yes, we know it's a mouthful, we're working on it. Enjoy!