6 Signs of Good Software Project Managers
The project manager is the redheaded stepchild of the IT world.
Developers don’t relate to him because he doesn’t know the difference between a float and that dollied-up car in a parade. If he had any skills, he’d be a developer, right? Real managers look down on him because he often doesn’t have any direct reports, and can only get anything done by whining loud enough. The customer sees him as a black hole of information; they call and tell him things, but their requests don’t always come back out the other end. Many times savvy customers will end up appealing to either upper management or a developer whose address they happened to see on a CC list during an email exchange. You know, people who can get things done.
With all the malice, the project manager must surely have some redeeming qualities. Why do we keep them around?
Mr Angry recently lambasted the idea that project managers could predict how long a project will take, and on this point I wholeheartedly agree. It is an unfortunate side effect of how projects are obtained and billed that causes us to try to take a fundamentally unpredicatable process and attach mostly meaningless numbers to it.
If the software company is responding to an RFP, they are basically massaging numbers to get the final price to be something palatable to the prospective buyer. How long it will actually take is academic, since the company is in attack mode and wants the project. I’ve seen few companies resolute enough to stay away from bad deals if they know there is money on the table. If it is an internal development project, things get even more tricky. Upper management has usually already determined that the project will happen, and it is up to the project manager to retroactively determine how it should happen. They then have to concoct a formula that takes incomplete and often inaccurate information and outputs a time estimate. That it ever works is a miracle.
So project time estimates are clearly not the project manager’s forte. There are still many things that good PMs can do to make sure their projects at least have a chance for success.
- Manage Customer Expectations: Customers need to know early what is feasible and not so feasible when it comes to their projects. As the interface between the development team and the customer, the project manager is responsible for keeping their expectations in line with reality.
- Develop a Rapport with the Customer: People are not robots, usually. They generally enjoy interacting and working with people that they like, and having a congenial relationship with the customer allows the project manager more leeway when things don’t go as planned with the project. Things which could otherwise be escalated can be allowed to slide, and things move more smoothly.
- Understand Where the Project Really Is: Predictability is the name of the game when it comes to project management. A good project manager will understand exactly what the current status of development is, and won’t need to rely on developers’ accounts to decide if things are moving along correctly. Here, development methodology comes into play; new functionality should be available for testing and verification regularly so that the project manager can see it first hand. The more they know, the fewer the surprises, and the happier the customer.
- Increase Visibility: Poor documentation is the last refuge of lazy developers. I am a developer, and I freely admit that I hate documentation. I like to work at my own pace, and resent it when people make me write down all that stuff I have in my head. Unfortunately, that would make me a bad project manager. In that role, one should strive to put in place systems that ensure that every interested party can figure out whatever they need to know whenever they want it. If you treat development like a black box, customers get antsy because they always assume they aren’t being heard. The mechanism by which the status information is disseminated is open for debate. It could be simply a daily email of status updates, or making nightly builds or versions available for the customer to play with.
- Speak the Developer’s Language: Building a rapport with developers is also very important, since they are the horses you need to ride to the finish line. I have seen many cases where project managers take a hands-off approach and don’t take the time to learn about the actual art of software development. This hurts them on several levels. One, the developers take you much more seriously when you know what you’re talking about. Two, you know what you are looking at when it comes to evaluating the software; platforms have trade-offs and limitations, and it is important to understand these. Three, knowing about development helps in interactions with the customer. If the project manager understands that you have to redesign the database to accomodate some random, last minute request by the customer, they are probably less likely to agree to it in the first place. It is unrealistic to expect a PM to know development inside and out, but they should have the basics down.
- Know How to Say No: Project management is not a job for people-pleasers. It takes backbone (and probably some upper management support) to tell customers that what they want doesn’t fit in the stated project scope, or to tell the developers to get back in line when they start going off on tangents. This is where that rapport and mutual respect come into play; they are the grease that keeps the gears turning through the differences of opinion.
There are many good reasons why we have project managers. Although they are often unappreciated by those around them, they are critical to making software development happen. The best project managers are often the most inconspicuous since things happen so smoothly when they are involved.
Let’s make sure that they get recognized.
Til next time.
Posted: November 10th, 2006 under Business, Technology.
Comments: 9
Comments
Comment from James Collins
Time: November 10, 2006, 12:34 pm
Great article and on the money ! One thing to assist as well is to focus on being a PM. You can waste a lot of time installing and integrating Microsoft Project. I use Projity’s Project-ON-Demand and giving them props. This should be noted for your audience that instead of giving Microsoft big money you can subscribe to a complete alternative for $7.99/month. You can even open your existing project files and it is all in their browser. Just a shout out to a great option. You may want to post something to assist your readers. This was good to give guidance !
Pingback from Mike-O-Matic 6 Signs of Good Software Project Managers « Le Danois 2.0
Time: November 11, 2006, 7:29 am
[…] Good points for software project managers: Mike-O-Matic 6 Signs of Good Software Project Managers […]
Comment from Doug Karr
Time: November 12, 2006, 5:42 pm
Just curious how you differentiate a Product Manager from a Project Manager. This list appears to accompany both. Nice article!
Pingback from 좋은 PM의 6가지 징표 « re-thinking
Time: November 12, 2006, 10:12 pm
[…] Mike-O-Matic » 6 Signs of Good Software Project Managers Posted by tzara Filed in Tech/Biz […]
Comment from Mao
Time: November 13, 2006, 11:32 am
Very nice indeed…
Comment from marc
Time: November 13, 2006, 12:24 pm
As a former Project Manager, I can tell you that #6 and #2 are in conflict, on their surface. No customer wants to hear ‘No” and few are willing to. Saying “no” is an art, that mostly involves saying “Yes, but …”. An example:
Cust: I want XYZ feature, we really need it.
PM: That sounds great, it appears to me to be really vital. Let us take a look at it and we’ll get back to you on the schedule and cost implications.
(this is where the trust starts to come in)
Cust: But we really need it in version (next version).
PM: I understand, and want to help you here, but we’re working flat out now. Either something else goes, or we have to … (remind him of the PM’s square - scope, schedule, cost, quality - pull on one side, and you have the give up on the others, or add something to them)
Cust: Well how about …
The trick is to turn every request into a negotiation.
However, this is tougher until the customer sees that you can deliver on something of a schedule, within reasonable cost bounds. IF you can’t do those, then the perception is that ANY cost and schedule estimate (even for new features) is BS, and therefore, you can’t argue about adding new stuff.
Though I never used Project on other such tools for detailed planning, I would argue that most SW projects for a customer need broad schedules and cost bounds - very few customers can do without.
I would also take issue with “fundamentally unpredicatable process.” The process is not building a house, that’s for sure. But it can certainly be reasonably bounded, especially if using a spiral development approach. In my two years of managing projects, large and small, we always satisfied our customer’s expectations with respect to the PM’s square. (Part of that was Managing expections, for sure)
Developers have to remember that if you’re building SW for a customer, they have to be able to plan as well, and that’s why managers try hard to define schedules and costs - that’s what every business demands of their vendors. No one gets a blank check.
Comment from keldon
Time: November 15, 2006, 10:18 pm
In the seven years that I was a Program Manager I found a lot of what that article said to be true.
The old saying about Program Managers at MS is ‘all of the responsibility and none of the power.’
My biggest beef with most Program Managers has been not really understanding the technologies and problem space of the projects they are managing. It is essential to managing a software project to understand the technologies being used and the full problem trying to be solved.
Program Managers that create schedules without thorough consultation with all parties that are responsible for producing the deliverables should be shot and fired – not necessarily in that order.
The best Program Manager is an empowering, facilitating scribe. Facilitating the different teams and members of each team to communicate and collaborate while empowering the individual contributors on the project to be able to do their job well, and ongoingly broadcasting the project requirements, decisions, plans, issues, and current status of the project to all involved.
Program Managers are the translation plate between the business teams ( The Customer, Marketing, Sales, Business Development ) and the technical teams ( Dev and Test ) and as such understands both worlds and can communicate to everyone in their language.
Example : explaining to the CEO why a very desirable feature is not technically feasible in a way that the CEO can understand, then turning around and explaining to the developer why the ‘stupid’ feature that makes no sense to duct tape onto the architecture of the project isn’t stupid because it meets the overall business requirements of the project leaving the developer focused on the technical challenge instead of challenging management’s intelligence.
Knowing when and how to say ‘No’ is super super critical – this bears repeating.
Comment from phlyhunter
Time: November 15, 2006, 10:40 pm
Good project manager does not just predict (or throw dart and pick a date), but He/She must know how to plan, estimate, and schedule
From dictionary.com
es‧ti‧mate /v. ˈɛstəˌmeɪt; n. ˈɛstəmɪt, -ˌmeɪt/ Pronunciation Key - Show Spelled Pronunciation[v. es-tuh-meyt; n. es-tuh-mit, -meyt] Pronunciation Key - Show IPA Pronunciation verb, -mat‧ed, -mat‧ing, noun
–verb (used with object)
1. to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately: to estimate the cost of a college education.
2. to form an opinion of; judge.
–verb (used without object)
3. to make an estimate.
–noun
4. an approximate judgment or calculation, as of the value, amount, time, size, or weight of something.
5. a judgment or opinion, as of the qualities of a person or thing.
6. a statement of the approximate charge for work to be done, submitted by a person or business firm ready to undertake the work.
——————-
pre‧dict /prɪˈdɪkt/ Pronunciation Key - Show Spelled Pronunciation[pri-dikt] Pronunciation Key - Show IPA Pronunciation
–verb (used with object)
1. to declare or tell in advance; prophesy; foretell: to predict the weather; to predict the fall of a civilization.
–verb (used without object)
2. to foretell the future; make a prediction.
Comment from PM Hut
Time: January 27, 2009, 1:52 pm
I like the first paragraph in this article, it is to true especially for the developers’ part. The main issue on why project managers are look down to is because they are, by default, given responsibility without authority. Imagine that you’re given a car, and you have to give someone a lift the to the airport, but you don’t have a driving license. That’s what a Project Manager feel.
I have published a series of articles on PM Authority, the series acknowledges this issue and presents ways to establish your Project Management authority.
In all cases, if you don’t have support from upper management/functional management, then it’s better to move elsewhere, or spend your day, every day, begging other people to do their tasks.
Write a comment