Home | Login | Recent Changes | Search | All Pages | Help

SessionOne039

Advanced Project Management: Beyond the Common Skills
JohannaRothman and MarieBenesh

There are lots of places to learn about the common skills for Project Managers�..this is the place to learn about uncommon skills, such as: managing up and across; keeping project sponsors and champions engaged; creating teams, not just groups of people. We�ll take your current nasty project problem, and work with you on how to solve it.

Key Learnings

- Understand the politics of projects

- Understand the keys to effectively communicating with your sponsors and senior management to maintain their support

- Recognize the signs of conflict between project communities and learn some techniques for resolving them

- Learn the one phrase you need to know to keep a project�s scope in bounds

We wrote up the points we wanted to discuss to give you an insight into our heads:

Advanced Project Management goes beyond just managing the schedule and the basic software requirements. It involves knowing how to solve the gritty problems that often come up during a project; the one�s that can drive us crazy if we don�t have a strategy for dealing with them.

Let�s discuss some of these typical but often maddening situations:

1a. People ask you to fit more work into the schedule, but maintain the same delivery date. What do you do?

• If the work they ask you to do is really beyond the scope of this release, say so. Start to get buy-in for a release-based implementation and add the new requirements to your phase 2 plan.

1b. What if the work they want you to do is something that would really make a difference to the final delivery and you feel you �should� do it?

• This is the time when you need to call upon your whole team to look at possible solutions. Could more resources really help? If so, how do you get them. Did you build some slack into the project that you could use for this purpose or is it too early in the plan to take that risk? Is there a powerful sponsor that you could enlist to help you get the right adjustments to schedule, resources, etc?

#2. What if you have two equal stakeholders in the project, i.e. two customers, and they have conflicting requirements?

• The best way to manage this is to get those two sponsors into the same room and get them to help you figure it out. Don�t let yourself be caught in the middle of their issue. Be the facilitator and help them to see the implications and risks that go along with their proposals. Help them to work toward a set of options that they can both live with.

#3. How do you know the project is done? How do you keep the project from hanging on?

• Defining �DONE� is one the first things you need to do when building the Project Charter. Explicitly define the completion criteria, including documentation, etc. Define completion criteria with the project team, using all aspects of what done means for this product. Use the completion criteria (release criteria, acceptance criteria, ship criteria) as a way to gauge project progress.

#4. Who makes the decisions on this project�..what kind?

• Decision-making is one of the most critical areas of project definition. At the start of the project the decision-making matrix should be documented and communicated to everyone on the project. This should include who makes system change decisions, policy decisions, requirements changes and timing and cost changes. There is often more than one name on each of these, and it could be a steering committee or a sponsor.

#5. How do you keep your sponsor interested and engaged in the project.?

• Establish with your sponsor the roles and responsibilities of each of you. Yours to him/her and theirs to the project. Be sure and establish a regular communication schedule of face-to-face meetings with the sponsor up front. Keep the sponsor engaged by letting them know what is happening on the project that is within their interest area. Don�t bore them with programming details, but keep them posted on capability delivered, policiy issues that you have resolved, etc.

#6. How do you build slack into the schedule�and should you?

• Critical Chain/Theory of Constraints suggests you put any slack at the end of the schedule. There are a bunch of excellent reasons for this: a) people tend to wait until the last minute to start something; b) we don�t know necessarily estimate well, and putting the slack at the end allows us to borrow slack from tasks that didn�t need it and put it onto tasks that do need it. Even if you don�t use critical chain project management techniques, have people differentiate their estimates from their fudge/slack factors�so that the learn how long it takes them to do their work.