Forums

I recently took over day to day operational responsibility of my 15-person company. As part of an overall change in strategy, we need to make substantial changes to our product. To do this effectively, it is necessary for us to bring our software development in-house (its currently outsourced off-shore).

My concern is with staffing. I have hired new two fantastic developers to join our in house team of one solid developer and a project manager.

It is clear to me (and confirmed by both the in house and offshore teams) that the PM is not getting the job done. His communications (both written and verbal) are too often long-winded, incorrect, imprecise and evasive. I've taken over 70% of his responsibilities over the last two weeks, but this is not sustainable because I am non-technical, and have the rest of the business to run.

Long story short (too late!), I know I need to get rid of this guy, but I'm not sure exactly how or with whom to replace him. My new Lead Developer (who has convinced me to adopt an agile dev process btw), says if we need a PM at all, we basically need a traffic cop to track work flow, coordinate schedules, meetings etc.

This sounds to me like I need an admin with a CS degree. Does such a position exist and if so, is the correct title for it project manager? The larger question, of course, is: based on this limited information, does this proposed job description make sense or are there better alternatives that others have found?

akinsgre's picture

First, I think others will have a lot to say about "knowing" that you have to get rid of this project manager. Can you talk about what steps you've taken to help him change his behavior?

But in terms of PM on an Agile project, you can look at the role of a Scrum Master. This job not only exists, but there are certification courses. A Scrum Master is responsible for helping to facilitate a team (removing impediments, acting as a liason to Product owners).

What I see as the real difference between PM in agile, and PM in non-agile process is that there is less emphasis on Gantt charts and the like, and more emphasis on building relationships.

Checkout the Controlling Chaos podcast for some conversations about Agile Project Management.

Good Luck!

adamjep's picture

That's helpful, thanks.

The job absolutely calls for someone who is relationship oriented and has clear written and verbal communications. Much less concerned about gantt charts, etc. Will check out the podcast (how did I miss it?).

I know its time for him to go because I've been very clear about how he needs to change his behavior and why, he's recognized these things, made improvements for limited periods of time and then fallen back on old habits. There's only so much time I can devote to continual rehabilitation and feedback. And he's lost the trust of the close-knit team.

shirgall's picture

The most important skill of the PM is communication. If your PM is communicating poorly you need to coach him around to the right course or find someone that can do the job properly. Not only are you a stakeholder in the project, you are the project sponsor. A PM should have determined early on what you needed to know, and how, and made it part of his job.

The "traffic cop" role of a PM is more properly called "project coordinator". If there is not someone handling real planning and keeping everyone on top of what is going on, the project is not managed, it is [b]observed[/b].

Is there an established plan and a process to change it that lets everyone know what's happening? Do you know what's going on and what's next? Are you aware of what risks are being tracked and the plans for dealing with them? If you desire all these things you want a project manager. If you just want to "keep score" hire a project coordinator.

suedavis's picture

Talk to your lead developer some more; if they have a clue about agile processes, and if your team is just three people, your lead may be able to step up into providing enough project management to make hiring a PM unnecessary. A well-run agile project already does the inward-facing parts of a PM's role as well or better than a PM you could hire might, and with support from management and a good customer surrogate to set priorities, your team might already have what it needs to be successful.

And if you're keen on your lead developer, this is a good chance to give them some additional responsibility.

suedavis's picture

Oh, wait... this is an older conversation, and it's just that last post that was posted recently. So, what actually happened, and how did it go?

pmhut's picture

Developers usually hate Project Managers. I wouldn't have taken his advice myself.

Allocating your developer to take a PM role (in one way or the other) might be the way to go, but you should know that this will mean that you're going to lose him as a developer, and you'll soon have to hire another developer. You should also understand that not all developers excel as Project Managers, but then again, as you said, your previous PM was a bit lame.

erikko's picture

if that's the case, there must be a middleman that should bridge the gap between Project Managers and developers

shirgall's picture

A good project manager would either know how or would quickly learn how to communicate with the developers to get the information he or she needs and convey the information they need in an effective manner. Having worked with a number of developers myself, I can say most of them hate interminable status meetings where 200 people go around the table and say they are "green". I don't bring developers to those, I bring developers to very small one-on-one meetings where they learn to trust me to ask them some important and meaningful questions about how their part of a project is going, to tell them what they need or want to know about the rest of the project, and to protect them from other people asking them stupid questions. On top of it all, I will get them the help they need when things go awry.

Middlemen interfere greatly in this important process (and this process has to be done with every stakeholder in your project). Middlemen are not effective and are the #1 reason the Manager Tools gods hate matrix organizations. All projects worth the name create temporary matrix organizations to get the job done, and we have to learn from that cast as well...

AManagerTool's picture

[quote="erikko"]if that's the case, there must be a middleman that should bridge the gap between Project Managers and developers[/quote]

Office Space Movie Question: Who was that guy whose job it was to take the requirements from the users and give them to the developers because they had no people skills? He ended up being happy because he got run over by a car or something and could retire(crippled) with his lawsuit money.

stephenbooth_uk's picture

I don't know the name of the character but the role you just described sounds like a Business Analyst (well, one form of Business Analyst, there are a number of different jobs that have acquired that title). Basically someone who can translate between business speak and technical speak, gather the business requirements and turn them into something that the developers can code.

The International Institute of Business Analysis have a [url=http://www.theiiba.org/AM/Template.cfm?Section=What_s_a_BA_]fairly good description of this sort of BA[/url].

Stephen

AManagerTool's picture

Answer:

Tom Smykowski: [Smykowski is in a full-body cast] Just remember, if you hang in there long enough, good things can happen in this world. I mean, look at me.

Would you believe that the actor who plays him has been in 201 movies to date?

mtietel's picture

Tom Smykowski: [Yelling at the consultants] "Well look, I already told you: I deal with the g**-d*** customers so the engineers don't have to. I have people skills; I am good at dealing with people! Can't you understand that?! What the h*** is wrong with you people?!"

Absolutely classic.

US41's picture

[quote="pmhut"]Developers usually hate Project Managers. I wouldn't have taken his advice myself.[/quote]

Determining if a project manager is skilled at his job is not accomplished by asking the other project team members how he is doing. He may be doing an incredible job of whipping them all to deliver their work on time and holding them accountable. He may rock at cornering them into attending meetings and forcing them to make tough decisions. He may be awesome at shining a light on bad behavior in meetings and getting status together to tell you how well they are, or are not, performing.

And not only the developers but everyone else on the team will think the guy is a jerk - whether he stinks at his job or not.

The way you determine the skill of a project manager is by reviewing his project with him regularly and going over the project documents he's using to record and plan activities.

* Review his status reports to you that he provides in writing. Do they tell you where the project is at? What issues are currently blocking progress? Do they tell you the next steps to be taken, where he is on the current plan, and if success is expected?

* Review the plan in detail regularly. "Why did you give 5 days for getting new equipment? The ordering system is online, the form has eight fields, and they offer next day delivery." Or, "It shows here you started the software testing phase three days later than you had planned to. What gives? How are you making this time up? Should I expect you to beg for three extra days down the line, or should you be statusing me on this now that the project is in trouble?"

* Review the requirements of the project. You don't have to be a master of requirements - just force yourself to pour over the details. You need to know what is needed to make the project a success.

* Review the budget. What tangible goods, land, or whatever must be rented or purchased? How will it be shipped? What expenses were not thought of?

When you have a true master project manager, when you review this stuff, they are very confident, they have the answers and more, you get status constantly, there are zero surprises, and you get what you wanted on time and on budget because they properly planned and adjusted with you way in advance of actually violating the original plan.

BTW, in my experience, there is no certification for project managers that predicts an ability to do this job in a superior way. The best I have ever seen had no certification or training. The guy I fired faster than any other PM I've ever made the mistake of hiring had more certifications than anyone I know and was a PhD and had earned every other certificate you can imagine. I have worked with hundreds of PMs and have managed more than 75 total so far - I have seen no correlation between certification and ability yet.

[quote] Basically someone who can translate between business speak and technical speak, gather the business requirements and turn them into something that the developers can code. [/quote]

I think that is kind of a myth as to what a business analyst does in an IT role. In fact, what a BA actually does is turn business wants into tightly organized, very concise, numbered, single-simple-sentence statements of what the business' vision for the eventual outcome is. He doesn't actually write anything technical at all, and he doesn't have to know a thing about code or technology. A BA has to be able to boil down something that seems very complex to a marketing guy and turn it into a five word sentence.

Example Marketing Guy:

"We need to be able to get in there and make changes to people's accounts without having to log out and log back in every time a new user comes to the terminal."

Example BA translation:

1. Provide the ability to update account information
2. Allow multiple users simultaneous access

Now, this might not be a good idea to IT because it will lower security, but the business guys might not give a damn. At any rate, the demand is stated clearly.

Some big shops take the business requirements a BA writes and hand them over to a system analyst who writes a system requirement. Then that is translated into a design. Then that is translated into a detailed design.

In a small shop, the business requirements may be handed to the developer to code from. They are not translated for him. The developer is expected to speak "business" and he turns those statements the BA made into code reality.

NEVER put system design or non-business remarks in a business requirement. When you do that, here's what happens: people who do not know anything about software design end up doing the designing, and the developer, now cornered politically, delivers crap.

IT will shrug and say, "You made me do this."

juliahhavener's picture

I realize this is late - but this is another excellent post by US41.

I find more and more that I often play the important role of 'translating' between our customer service group and our analyst group. One of my peers says 'I want a report that does X, Y, and Z.' The analyst builds exactly what is requested...but it isn't really what my peer wanted. Peer gets upset and says 'No, this should be X, Y, and Z!' Developer says 'Yes, that is precisely what I gave you.'

I hear from both sides how stupid this discussion is, and immediately identify the issue is some unspoken qualifier between what my peer wants to KNOW and how they think they get that answer. The analyst doesn't know a lick about what the data is supposed to show, only the parameters they were given. It's an interesting place to be, and I've learned a lot from it, but I guarantee you there are days I'm incredibly un-popular with both sides.