Monthly Archives: May 2009

Post navigation

Usually, project managers are assigned to a project from the beginning to the end. This strategy has its advantages as continuity and strenght relationships with stakeholders.

However, there are other ways to assign project managers.

A program manager should consider assigning a more senior PM for the kick-off or initiation phase of a project to ensure a good beginning. Once the project is defined, the goals are approved and the baseline is established, you can execute the project with a more junior PM.

To perform the transition at the start point of the execution phase is something easy if you have all the information agreed from the initiation phase (project definition, baseline…).

Close projects is too a critical stage in projects, some projects needs a more senior profile to close the project and avoid the closing phase to be exceeded for a long time (with bad economic consequences for the project). The transition in this phase to a new PM is more difficult at this phase of the project, but an additional support to the junior PM can be enough to ensure a right close of the project.

this is all I can tell you today 🙂 . There are thousand of methods to ensure your delivery: check-list, best practices…. but other necessary step of this process is to say “…eh man, can you have a look to this plan?…”

I always try to do it, and today I did it with someone who came to take a cofffe on the machine close to my desk. I was lucky, it had 2 mistakes that would be very inopportune during the presentation.

Peer reviews are very common on software development as step of the development lifecycle.

One of the problems we have with some of the Project Managers of the team is that we do not do peer reviews. This easy look on the documents we deliver should improve the quality of them.

Yes, we need more time then… more time?? … no way.

Then the only viable way I know is to seat the PMs one next the others. That is the best way I have worked as PM. I can share things that other can understand, I can ask for quick help, I can make jokes the other understands…..

As you probably know, that’s what you can listen in more projects that you expect.

I have seen how people look at the planning asking themselves “why the project does not run as expected??. They perform continuous analysis of EV, SPI, CPI….

Sometimes, they check the estimation to reduce other tasks that are not affected by the delay in order to fix the big number.

Then they check the actions that are delayed and make pressure on them. After that they evaluate again and decide what are the next tasks to put the pressure on.

It makes team to be continuously on pressure and without understand where to go.

Please don’t fall in this error:Dear PM, the work to be done has a behaviour as a whole, forget the plan and concentrate you and your team on the product you have to deliver.

Create this vision of the product of the project on the team takes time and a lot of communications.

Are you stressed? probably yes, but transmiting this stress to the team you won’t have the project done, you’ll have an stressed team. You need to be very mature and keep calm to create the vision about how to get the product done, then communicate your vision to the others.

As in beisbol, in your team you can have good pitchers and good catchers.

In this case I define a pitcher as the person with a high proactive attitude who follows the team to perform the activities and that creates the next pack of activities to allow the team working on the next step. They are good motivating, creating and providing new vision to the rest of the team. Throwing, throwing and throwing balls, good balls!

On the other hand, catchers are people who are good receivers of pressure and large amounts of workload. They are good prioritizing activities, staying calm, working under stress.

As in sports where different positions are needed, in project teams it’s good to have people who can play different roles quite naturally.

It’s important to understand it, due to you can have a good catcher playing as a pitcher and you can think, “…he was very good!!!…why he’s now doing bad!…” In this case the wrong decision has been done by the coacher: that player is on the wrong position. There is not just skills, capabilities and background, there are attitudes towards the work you have in front of you.

This graph is obtained from a macro created by the team that provides the corporate PM toolset for all of us. Nevertheless the values I mention are extracted from MS-Project data, so you can also do it.

Returning to the weird issue, the cumulative work at point #1 is suddenly increased, being separate with respect BCWS, that stated below.

Other interesting item is the fact that 1 month after point #2, both curves remain again parallel. This behaviour was understood when we reviewed the milestones view:

You can see that there is a period of 3 weeks where there are a lot of deliverables marked by the milestones.

Due to the current delay the project has, and the confluence of milestones in a given period, all work that has not been done is accumulated just before the milestones were reach. That’s way the cumulative work is increased by MS-Project, she is telling us: “… ups, you need to increase your effort to reach the milestones!!”

The forecast of the rest of the project is calculated taking into account that you are going to reach the milestone events properly.