We Don’t Need No Project Managers!
By Alora C. Chistiakoff
As I look at job postings on Dice and Monster, I have been noticing a disturbing, yet unsurprising, trend emerge: an increase in the number of employers seeking candidates who can function as both project managers and development leads on projects.
Naturally, difficult economic conditions demand a re-evaluation of spending habits. And, in cases where projects are reasonably small, there are very few stakeholders involved and requirements are very straight-forward, I would never argue that project management should be full-time. I am a firm believer in the value of tailoring the project management process to meet the needs of both the project complexity and the organizational maturity. So there are absolutely times when doubling up on roles makes sense.
However, before you decide to swap out the PMPs for the Developers with decent leadership skills, consider the following five questions carefully:
- Who are the (non-project team) stakeholders for this project?This is one of the most important questions to consider. If your “project sponsor” is your Director of Engineering, then maybe having the development lead function as the project manager makes sense. After all, presumably they already have a standing working relationship, comperable communication styles and are often coming from a similar view point in crafting a solution.
But what if your stakeholders are not technical people, but non-technical business clients (either internal or external)? Is your development lead the best person to communicate with non-technical project stakeholders about things like status, risks, issues and process implications? Is it good for the project’s outcome for the development lead to spend several hours of his week in business meetings in which decisions are debated or designs are evaluated, instead of leading the technical team in matters of architecture and design?
- What technical disciplines need to be involved for this project to be successful?
It is rare for any project to be exclusively a development effort. Most technical projects also require DBA, server, network and QA resources; additional ones such as design and documentation can also be critical, depending on the project. A common problem in having a project managed by a developer is the tendency for a natural bias towards application development at the exclusion of the other technical aspects of a project. And even when the development lead is actually unbiased, it is not uncommon for organizational politics to foster an illusion of bias from the point of view of other technical team members. A project manager often has an easier time being perceived as unbiased, and therefore establishing mutual trust and team cohesion.
- What are the finances for this project?
Does your organization track specific department and/or project budgets? Or are you operating in a ’slush fund’ organization that doesn’t clearly delineate one department’s budget from another department’s budget? If so, then maybe cost management isn’t a huge deal and internal projects can be allowed enough leeway that managing to a budget isn’t a primary concern. Or is yours a sales-driven organization that is running client projects on a time and materials basis? If so, then there is no way that cost management isn’t a huge element of successfully delivering the project to ensure that the client doesn’t have a rude awakening with a bill they were unprepared for or your organization doesn’t find itself eating unexpected costs because a project was allowed to careen out of control.
- What is the level of technical complexity of the solution being implemented?
This is one of the most dangerous questions, because it has been my experience that developers are often highly optimistic people when it comes to estimating both technical complexity and time needed to implement a solution. As such, one of the single most common mistakes I have seen repeatedly occur in projects led by developers is a tendency to underestimate both the technical difficulty (particularly when it comes to what non-dev technical resources will be required: servers, network configurations, etc.) and the amount of time needed to make it work. While I applaud the nearly universal ‘can do!’ attitude of almost every developer I have ever worked with, one of the principle functions of a good project manager is to protect the team from overly ambitious (if not out-right unrealistic) timelines and expectations. And, truth be told, often times one of the most important things a PM does to that end, is to push back on team members who give simple, shiny answers to technical questions that are long on optimism and short on details.
- Is there any outside procurement of goods or services needed for this project to be successful?
Again, if this is a fairly small project that can be successfully accomplished with the people and resources you already have within your organization, then great. That should help simplify a number of things. But as soon as you start needing to look outside of your immediate team for any goods or services — servers, third-party applications, consulting services, new business partners, etc. — you are opening up a whole huge can of worms. Drafting RFPs, evaluation RFP responses, selecting vendors, negotiating contracts, managing vendors, monitoring financials/billing and more are part of the endless fun and excitement of procurment. Is this something that your development lead is ready to do? Or, even more importantly, is this something your development lead has the time to do and still deliver the code on time?
Project Managers are not over-paid admins. There is a lot of work involved in successfully delivering a project and meeting the expectations of stakeholders. Per PMI, Project Manager’s spend 90% of their time communicating — with sponsors, with team members, with clients, with finance, with functional managers, etc. The best project managers tend to be extroverts; and the best developers tend to be introverts. Each role has different needs and therefore attracts different types of people; it is rare that one person is very good at both.
But even assuming for a second that you have a development lead who is a strong communicator and who understands the integration challenges of successfully launching a project (and I have met plenty of very talented developers in my career, and any number of them had the skill set and desire to be perfectly good project managers), if they are also expected to function as a development lead on a project, all the skills in the world don’t make up for the one thing they need and do not have: TIME to do both jobs.
Be wary of falling into a trap of being ‘penny wise and pound foolish’ when it comes to staffing your projects. Expecting that a development lead is going to have the bandwidth to fully manage all critical aspects of a project and still be able to lead development efforts is a dangerous gamble. And one that rarely pays off.
Alora C. Chistiakoff has spent a decade managing projects, leading change initiatives, developing teams and implementing technology solutions in startup and entrepreneurial environments in the Bay Area, NYC and now Austin, TX. She blogs regularly on business, leadership and career management at The Pragmatic Contextualist.