Project Managers almost always find themselves in the middle of conflicting interests. On the one hand, marketing wants a project finished immediately. On the other hand engineering is going to need much, much more time than they’d ever imagined in order to get the project right. On the other hand, management wants to do the project with less money. On the other hand, sales needs new projects started for which there are no resources.
In the face of that kind of multi-faceted situation, the pressure to please is enormous but just trying to please every request is rarely a winning solution.
Let’s take a situation I live in my firm every day. Our own product, TimeControl, is a commercial-off-the-shelf (COTS) application. It has been used by thousands of firms and hundreds of thousands of users worldwide. Yet, on a weekly basis or so, one of our staff is asked for functionality that is not in the product.
For some organizations this would not be a problem but in our environment, our developers, technical support personnel and implementers all rotate rolls. We do this very deliberately as we find that programmers who have to support the code they wrote, tend to do better quality code and technical support people who go out into the field to deploy our software tend to be much better about seeing things from the client’s perspective and implementers who know the product at the code level can see how things work within the product intimately.
On the one hand, this tends to produce rave reviews from clients who always experience technical or implementation support as though it had already been escalated to the top level but on the other hand there is a distinct challenge that we have to deal with.
Our technical staff are all people-pleasers and, given they also develop, they have the skills and access to answer questions in a way that most implementers would not.
So, every few days we get a request from a client for functionality and our programmers are only too pleased to think about how to create it.
We have checks and balances around TimeControl to make sure that such requests or the desires of our eager-to-please technical staff won’t change the product with a change that hundreds of thousands of users might then have to deal with. We’ve been doing this for about thirty years now so it’s common ground for us, even if from time to time it frustrates our technical staff. The end result though is that HMS and TimeControl get the best of both worlds. But it’s a process that requires regular vigilance
Project Managers face this same challenge every day.
The marketing staff wants it sooner. So the eager-to-please project manager will feel enormous pressure to get engineering to get the project done faster.
Management will want to improve the bottom line so the eager-to-please project manager will look at how he or she can cut corners.
Engineering will want to give themselves more time to do more of the job they want to do. So the eager-to-please project manager will delay, obfuscate and misdirect to get them what they want.
It is likely that none of this will be productive in the overall scheme of things. Moreover, any project manager who encourages such discussion will soon find themselves at the nexus of misery as everyone involved will interact with them as though this is a zero-sum game. “If you give to that department, you have taken from mine!” The stress from this alone can be debilitating and I have seen project managers resign completely rather than face the growing upset of being pulled in different directions.
Project managers have a unique responsibility to carry a detached perspective. They must be looking from outside the morass of which department wants what to see what would be best for the organization overall. It is up to them to point out to the relevant stakeholders the trade-off for the requests they are making.
Yes, you can cut corners. But, how will that affect you negatively in the months and years to come?
Yes, you can do it faster, but will you end up with the result you need to be first to market and able to dominate it with that functionality?
Yes, you can make the ultimate mouse trap but will you damage the company by waiting for it and does anyone want to buy the atomic mousetrap?
I think Project managers have a responsibility to be the pivot point for all of those conversations because they all resolve themselves at the project manager’s desk. And, just like I have to do with TimeControl, the project manager has the tools to see the entire picture.
