9

I have been asked to takeover managing a project that has no structure in place; the only documentation is the initial brief, contract and a broad schedule including a product layout. The owner of the project has now left and there was no handover. The project is still viable and the team have been working on the project ad-hoc, where should I focus for the remainder of the project?

Improve this question
2
  • 2
    How does this situation differ from just "managing a project"?
    – yegor256
    Commented Feb 28, 2011 at 21:27
  • @yegor256 : At least, there is already a bunch of work done, with unknown results, since there is no documentation available.
    – Alexis Dufrenoy
    Commented Apr 5, 2011 at 12:10

7 Answers 7

Reset to default
10

My first piece of advice is to resist any temptation to implement a formal structure just to make everything look official. Start by evaluating the health of the project; determine what has been working well, and what has not, if anything.

To answer your question of where to focus: focus on what is working well and keep those things the same. Make sure you are comfortable with whatever status update tools are in place, and if there are none, start there. If the project is going well, don't rock the boat by introducing a new set of rules.

If there are a bunch of things that are not working well, take a pragmatic approach to implementing tools to address those needs. Are there unaddressed risks? Create a Risk Register. Is there a lack of communication? Develop a communication plan. Are there unclear expectations of the project team? You get the idea...

Good luck!

Improve this answer
0
3
  1. Meet with the client / the person you're doing the project for
  2. Find out and confirm what they are expecting and what they want done
  3. See if that is doable or not
  4. Get back to them and let them know what you found out in terms of feasibility (of scope, schedule and budget).
  5. Iterate until you come to a realistic plan (this process will also allow you to build a relationship with them)
  6. If feasible, execute. If not, stop the project.
Improve this answer
1
  • @Laura, Like Mark Philips I believe that the first thing you absolutely need is a sense of direction. Where are you heading? You must at least know a basic set of requirements, whether this can be done and does the sponsor support it fully in the way that you understand it?
    – asoundmove
    Commented Mar 2, 2011 at 2:35
3

You don't say how much longer the project will continue, the scope or what happens after the project ends...making a response a little difficult. If the project is delivering as 'expected' (based on some upper managers perception since there's nothing documented to gauge it against), focus on the post-live hand over. Help with communication in anyway possible (without interfering with existing communication lines), keep your eyes/ears open for any rough areas/risk points that you can apply your time to...and help QA as much as possible (end of an un-managed project often delivers interesting results)

Improve this answer
2
  • Good point. If this project is a week from delivery, it is a different story!
    – Marcie
    Commented Feb 28, 2011 at 20:35
  • Thank you for your answers, i will endeavour to include more information in future posts.
    – Laura
    Commented Mar 1, 2011 at 11:58
2

Since there was no official hand off from PM to PM, you're in a position where you're going to have to go through the hand off procedure with one or more team members on the project.

There's a strong likelihood that some of the team members know more about the direction of the project than you do. Initially, you're going to need to meet with these team members more often than you normally would.

Just like switching any resource in the middle of a project, switching project managers will cause delays as well. Make sure the change is communicated to everyone you'll be working with. Introduce yourself and clarify that you're in the process of picking up where the old PM left off. Let people know you're interested to hear their opinion on the project.

Ask questions about where the previous project manager was going with the project. What goals did he/she set? What was the plan for the next 3 months? What are the major problems on the project? What blockers are impeding progress? Ask their recommendations.

First and foremost, document everything. Documentation will help you make notes in your own words. This will not only serve as a reference to you, but the act of documenting things will actually help you commit things to memory and facilitate a greater understanding of the project.

At this point in time, the single, worst thing you can do is start blindly, arbitrarily implementing changes. Your job right now is to observe, ask questions, and learn as much as you can about the project so that you make educated decisions in the near future.

Improve this answer
1

I would say take your time before you come to conclusions. No documentation and no structure are not the same thing. Most managers often tend to mix up the two when in reality most experienced development teams tend to have their own silent structures which are not evidently visible when seen from the outside.

I would have to agree with Criag that trying to put too much structure too soon often creates more problems than it solves. See what is working and do it more often. One advice I can give you is spending a lot of time playing with the actual product or application and understands it’s functionality inside out. Use verbal communication and quick one on one questions instead of calling meetings. Maybe even start filing a couple of bugs along the way if you bump into bugs.

There are multiple benefits to this.

One is you can focus on the project by being hands on and without intruding into the time and space of others in the team who might already be busy.

Plus, that way you get to work on the application, know it inside out.

Not just that you get to know and work with the development team directly. If they are any good and if the project has survived thus far, chances are that they are using some sort of a structure (Test Driven Development, Unit Test Cases etc.) already. It just isn’t evident or visible to you. Working with the team will allow you to get to know them, know what existing development methodology they are using and what their skill levels are. Maybe they are talented programmers who are getting away by using a very light weight process and trying to rush in to add more management structure might add more problems than it might solve.

After spending some time being involved with the project hands on you might be in a much better position to take better decisions on the kind of changes that might benefit the project rather than rushing in and trying to make changes to the structure and workflow of how work is getting done. Then start making very small incremental changes, one step at a time.

On the client side, focus on constant communication and see if they are happy with the current output that they are getting. Again, if they are happy, I don't see any reason to rush in and make radical changes to the overall process. If they aren't happy, it would boil down to addressing one concern at a time. Very simply, avoid big bang changes on either side if possible.

Improve this answer
0

Start by trying to capture top-level requirements. Then do what the other posters suggest.

Improve this answer
0

Begin by knowing the current status of the project:

  • Ask the team about the situation, especially what are the current issues which could jeopardize the project
  • Check with stakeholders to confirm what is to deliver, and if they already saw anything working

Once you got these infos, you have to address the issues you learnt about.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.