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.
Do you have any other strategy?
Some lines extracted from The handbook of Program Management by James T Brown.
- Stakeholder management involves everything necessary to control relationships with all individuals the program impacts or affects in order to ensure the achievement of program objectives.
- Program managers must mentor & coach projects managers in terms of stakeholder management.
- “Hell hath no fury like a stakeholder scorned”.
- The goal of precommunicating is to eliminate any possibility the stakeholder will surprised by something at the milestone review.
- Program & Project Managers need to champion and lead their project and not to be intimidated by a stakeholder’s position of authority.
- Program managers should check up on how well project managers are doing their projects. This quality check should be informed to the project managers from the begining.
How useful they are,
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…..
I’m doing an estimating training and working on an estimation tool for a local client. This is keeping me concentrating on this knowledge area. I’m happy about it.
The tool I’m doing needs to balance best practices and simplicity. I can include a lot of features that helps to do better estimations but the key issue is the simplicity.
The consequence, I’m automatizing all that I want.
Some parts are more simple than I want but I need to do it so automatic in order do it easy.
The usability is also important, I need to do it so intuitive and providing easy steps for the estimation.
The most difficult issue is going to convince some people about the benefits of the tool; we need to do a good job in the communications and awareness.
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.
Have a good weekend
Play with numbers was something I always liked, so estimation is an activity that awakened my interest.
The rules to play are the best practices and common sense.
1.- A solid plan for developing the estimate, you need to have an strategy about what you are going to estimate and what you need to deliver, doing an initial tailoring assesment:
- Which level of accuracy do we need?
- Can I deliver this level of accuracy with the information we have?
- What are the expectations of your steering comitee and your client…
2.- You have an approved WBS with confidence that is clear, makes sense, and has the enough details: good start!
WBS is primary factor, it requires a vision of how the work will be done, this vision leads to the WBS which defines the work to be performed.
3.- Good Inputs :
- Ways to quantify — # of process threads, programs, workshops, # of types of activities…
- Prior Estimates — don’t reinvent the wheel!!
- Look at learned lessons,
4.- You need resources and reviewers who are skilled in estimating, yes skilled in estimating.
- Project Manager, or estimator who acts as mentor and coach to their estimating team. She works with the SMEs to define their WBS, drivers, resources, and estimate.
- SMEs who can envision “how the work needs to be done”. They have to know the product lyfe cycle.
5.- A tool for estimating, all companies have one. Never start with a blank template.
6.-Sufficient Time to the Estimate: estimation is an iterative process and you need time.
7.- Capture Assumptions,
- All the time you decide that some task is estimated by a reason, take a note of the reason, you are going to forget it and later you will have doubts.
- These notes will help to reviewers to understand why something take 30 hours instead 20.
8.-Multiple Reviews: four eyes see more than two!!
- Proposal Team,
- Sales Team,
- Delivery Assurance,
- Peer to peer review…..
There are more tips, these are just some of them.
Have a good day!
I continue trying to improve the vision I have on the ITIL life cycle model. Today I have reviewed the role of the capacity manager.
It’s supposed it is a strong technical infrastructure role that:
- Understands future resource needs, delivering these needs through a capacity plan (similar complexity to a project definition). This plan can includes forecasting and modelling.
- Defines the application sizing to ensure required service levels can be met,
- Defines and stores capacity management data that allows,
- to monitor, analyze, tune, and implement necessary changes in resource utilization,
- Manages demand for computing resources, which requires an understanding of business priorities. These resources can be servers, connections, help desk….
- Models & simulate infrastructure performance,
- Builds a periodic (annual, biannual) infrastructure plan with input from other teams.
- Is coordinated with the continuity manager, availability manager, data information manager, financial manager (who establishes economic constrains)…
A capacity manager is not a role focused on organizational capabilities or specialised on procedures or processes.
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.
Have a good day!
I have found this blog, http://www.noop.nl/ and I have read more than 10 articles without stop.
Added to my reader, this guy is very eloquent and the background very good.
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.
Are my conclusions right? If I’m wrong, please let me know! Thanks