Help me start off on the right foot with my new project team.
June 24, 2013 6:36 AM   Subscribe

I'm a newly hired, but experienced project manager who is taking over a project that is already underway. I've been out of work for a while so I'm super glad to finally have a job but I'm feeling overwhelmed and unsure of myself. I want to do an awesome job.

My team is not experienced at working on projects. They are smart, analyst types. The project doesn't seem overly complex - extracting data, determining business rules, sending the transformed data internally and externally, and creating reports - though it does have high visibility and importance. The team started mapping, determining processes and defining reports just before I joined. I am very unfamiliar with this business segment but I understand this type of project.

All project-related meetings are currently led by the stand-in PM who hired me. There are no project documents - definition, requirements, WBS, plan, etc. I will be working to get these created but I'm working with a team that is unfamiliar with these documents and won't see the value in them. However, I've got great experienced business analysts and they'll be working with me to develop timelines, the WBS and plan. (The current PM is experienced but swamped, thus my hiring.)

So, what should I be focusing on first as we shift responsibility to me from the current PM, who's staying on the team. In addition, I have a project coordinator and I've never worked with one before. How can I best take advantage of this resource? I want to come across as knowledgeable, confident and most importantly as helpful.
posted by anonymous to Work & Money (6 answers total) 4 users marked this as a favorite
 
Explain what you're hoping to accomplish with the different measurements and deliverables that you're bringing to the process. Also, ask them how they are currently managing this project, what works, what the pain points are, and how you can best be of use. The worst thing you could do, in my opinion, is jump in with your process because you think it's "better" and expect them all to fall in line with your way of thinking and doing things.
posted by xingcat at 6:47 AM on June 24, 2013


There are no project documents - definition, requirements, WBS, plan, etc. I will be working to get these created but I'm working with a team that is unfamiliar with these documents and won't see the value in them.

"Stu, what's your favorite thing to do on the weekends?"
[insert answer from Stu here]
"And what happens to this project if [insert plausible way that Stu's favorite weekend activity could kill him, or the old stand-by "you get hit by a bus"], or even worse, you get your dream job offer and leave me hanging? That's why we document our plans, requirements and processes, folks."

So, what should I be focusing on first as we shift responsibility to me from the current PM, who's staying on the team.

Make it very clear to the current PM that you are in charge now. Do this in private and as respectfully as possible, but he or she has to walk out of that room understanding on a gut level that you are the boss now, and when people complain about a change, his or her reply must be, "I know, it seems weird, but it's a good idea. Go with it."

In addition, I have a project coordinator and I've never worked with one before. How can I best take advantage of this resource?

Sit down with the coordinator and get a precise definitions of roles and responsibilities hammered out between you. Don't be afraid to tell the coordinator that you've never worked with one, so "And the usual stuff that a PC does" isn't going to be helpful.

As always, be a little stricter (with everyone, especially yourself) than you need to be at the beginning. It's easier to loosen up than tighten up.
posted by Etrigan at 6:52 AM on June 24, 2013


While I can understand wanting to have a better solution for this project ( documented requirements, plans) the best thing to do to is to familiarize yourself with the current processes/procedures on how X is done in the company before overhauling the system. I COMPLETELY agree that you shouldn't take on a task without having nailed down requirements (to ensure testability and prevent scope creep) - but it may rub some people on the team the wrong way if a new hire comes in and begins dictating terms of the project, without knowing anything about how X has been historically done,why it was done that way, and what the internal company procedures are. Having new project managers come in and start drastically changing a process - without any idea why the process was there in the first place - is always a big red flag for me, since it shows that they have a "my way or the highway" approach to things, as opposed to respecting what already exists, and then finding ways to improve it.

Also - make sure you have management buy-in for your approach. Nothing worse than trying to manage a project and having people on the project team go around you to management.
posted by Suffocating Kitty at 7:14 AM on June 24, 2013 [2 favorites]


definition, requirements, WBS, plan, etc.

All those things must exist for a project to be successful, but they might exist in a different form than you are used to. So I would first figure out what you need, then figure out what they have, and then map the second to the first. Once you have that figured out, create what is missing.

Then get the whole thing under configuration control. A list of requirements on a post-it on a designer's desk doesn't do much good, and the team needs to understand why. Be on the lookout for people spending time on things that exceed the requirements, that is common (IMHE) with smart people who are not used to working formal projects.

If you have that, you can be flexible on the format this time around.
posted by BeeDo at 7:36 AM on June 24, 2013


You'll get a lot more traction and buy-in if you spend the first few weeks/month while you're there primarily observing and asking questions. I worked somewhere that had no formalized project management processes in place that hired a PMP and although the processes she was trying to implement were sound, she just tried to jump in and change things and that ... did not work out well.

You'll need to start within the existing culture and then make cases for changing/improving processes. Yes, nail down requirements; work with the team to figure out task lists and time estimates; rigorously document agendas and action items, etc. But don't change too much until you do have an understanding of roles, culture, and current processes.
posted by Kimberly at 8:54 AM on June 24, 2013


Before you change anything, find out the way it's done now. When something seems less than the best way of doing something, find out why it's done that way by asking sincerely. Remember that "less efficient" methods are often the product of a few different things:

-it prevents something that is more difficult/more time consuming (remember that you may not have to deal with that thing they are trying to prevent). I used to get this all the time, where my boss didn't care that the thing that wasted 5 minutes of his time meant I didn't have to waste 2 hours of mine

-previous supervisor told them to do it that way

-everyone was trained a certain way, and even if they don't like it, they were never given the authority or autonomy to change it

-the techincal "solution" that upper management hyped and then forgot about never really worked right, and was abandoned once the attention passed
posted by spaltavian at 9:18 AM on June 24, 2013 [1 favorite]


« Older Loan Etiquette?   |   How do I get my guides to work across all layers... Newer »
This thread is closed to new comments.