Showing posts with label Objectives. Show all posts
Showing posts with label Objectives. Show all posts

Friday, March 14, 2014

PMO Creation - Week 4

Now that we have our schedule in place, we have been working well towards that plan. Sarah and Mike are cranking out templates for use by the team. I got them administrative rights to modify the PMO SharePoint site. Mike has been inventorying all the projects we currently have and I've been notifying people that they are on the steering committee. Everyone seems to be enthusiatic. Let's see how the steering committee meeting goes when we start asking them to make those tough decisions.

We also came up with a list of rules for the PMO to operate under:

The QPharma PMO will abide by the following rules and norms:
  1. The PMO will operate under full transparency, sharing information with all interested parties
  2. Escalation principles will be published and followed
  3. Nobody works on projects past the research phase until the project is authorized by the steering committee
  4. Projects can be authorized outside the steering committee meetings by approval of a majority of members
  5. All projects within commercial operations require a charter. Professional operations can use a Statement of Work or Signed Contract as their charter
  6. Project Managers will hold weekly status meetings with their teams that last 30 minutes or less
  7. Project Managers will use Earned Value calculations to report on budget
  8. Project Managers will provide a weekly status report to the PMO every Wednesday
  9. Schedules require level of effort to be calculated for each activity
  10. The PMO will provide a monthly dashboard showing all project status to the steering committee prior to their monthly meeting
  11. The steering Committee will meet monthly
  12. Change control will be managed by the steering committee. The PMO head will facilitate the steering committee but the signatures of the majority of members are required to approve a project change
  13. PMO will meet weekly every Friday at 10 AM
  14. Bruce will publish PMO status reports
  15. PMO members will obtain their PMP certification by the end of 2014

Monday, March 10, 2014

Dear PM Advisor. Mar 10, 2014

Dear PM Advisor,

I want to create a Project Objective using the rules you teach but you ask us to use one date and we need to have three dates: The key milestone, the release date and the date 90 days after release that indicates the real project end date. What do you suggest we do? 

Torn in Portland, OR

Dear Torn,

I do suggest that a Project Objective have one date in it. In facilitating over 300 Rapid Project Start ups, I've only violated this rule twice, where there was an initial start up date followed by a the full move to production. But in your case it is not necessary. Let's look at your three dates:

  1. Key milestone prior to release. This is important and should be reflected in the Schedule as a key milestone but it does not belong in the Project Objective. The Objective is the Headline of the project. Headlines should emphasize What we are doing, When and for How Much. 
  2. Release Date. This is the date that management wants to focus on. This date belongs in the Objective.
  3. End of the project after 90 days in the market. This is an important date to know and to emphasize to your team that they are not released until this date. Following the truism that 90% of the problems appear within 90 days of market release, we need the team members to stay engaged on the project until they have a chance to resolve all these problems. Put this date on your schedule and hold your team there until this date. Don't put it in the Objective. 
So you can get away with just using the release date on the Objective for your project. 

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

Monday, September 16, 2013

Dear PM Advisor. Sep 16, 2013

Dear PM Advisor,

How can you plan a project if you don't know who needs to be in the room? An Objective is such a powerful tool, shouldn't the right people be there?

I object from Columbus, OH

Dear Object,

Projects don't start in a vacuum. By the time you are ready to plan a project, one of the first steps being the creation of a Project Objective, the project has gone through many early phases. The names of these phases vary from one company to another but during these phases, the idea behind the project has been studied and researched, a business case has been made and the project has been authorized.

Somewhere during these early phases people should have determined the right team for this project. Not to say that during the actual planning we won't discover that someone else is needed we hadn't expected but most of the right people will be there. They can be trusted to craft a good Objective.

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

Monday, June 10, 2013

Dear PM Advisor. June 10, 2013

Dear PM Advisor,

You advise the teams to develop their own project objectives during their first planning session. That's all great and it must be pretty easy to meet this objective since you get the dates and budget from bottom-up estimates. But in my company we are handed those constraints from management before we ever start planning the project. How do you handle that?

Constrained in Maryland

Dear Constrained,

Don't be concerned. I'm here in the real world with you. Projects don't enter the planning phase from a vacuum. There is usually a lot of work done in advance before a project is authorized to enter the planning phase. And in these earlier phases there are promises made about budget and schedule. Regardless of how many assumptions and questions we attach to these earlier objectives, management is still hearing a date and a budget and expect you to meet these.

So the typical scenario is that your team starts planning the project but are told by those who authorized the project when they expect you to finish and how much money you are expected to spend. What you need to do is record that information as the management mandated constraints and then go ahead and plan the project from the bottom-up anyway. Answer all these questions:

  • What activities are required to complete the scope?
  • How long does each activity take?
  • How are the activities linked to each other?
  • How much does each activity cost? 

From the answers to these questions you will determine the bottom-up estimate of project budget and schedule. And they won't match the management mandated constraints. What do you do next?

Try some alternatives analysis to see if fast-tracking or crashing will reduce the timeline to meet the constraint. Try using cheaper suppliers or resources on some items. Remember that these techniques add risk and cost to the project. Look at reducing scope.

Then it is time to have the conversation with management. Here is the talk-track I want you to use:

  • You've asked for us to do A for $X by Y
  • We haven't figured out how to deliver A by that YET (Yet is a powerful word)
  • We can run these two deliverables in parallel but that adds the following risk
  • We can use this supplier and these cheaper resources to these activities and add this risk
  • We can add resources to these three activities and reduce the end date by this amount
  • We can reduce the scope by this item and bring the date to your expected end date
  • Please let me know your thoughts on these alternatives
Then allow them to make the trade-offs required to deliver what they can. It is up to the team to perform the alternatives analysis so that management has the facts to make the intelligent decisions. This is why they get the big bucks. This is another reason why you need to make assumptions in your activities regarding cost and schedule so that this alternatives analysis can be performed. 


Once management has made their decision, re-baseline the project and strive for early delivery of each activity so that you have some buffer when problems occur and you can still hit the deadlines.

Good luck,

PM Advisor

Send your questions to bfieggen@gmail.com