ICPM

This email address is being protected from spambots. You need JavaScript enabled to view it. This email address is being protected from spambots. You need JavaScript enabled to view it. The International Community for Project Managers
Brought to you by TenStep, Inc.
2363 St. David's Square
Kennesaw, GA 30152
877-536-8434 or 770-795-9097

This email address is being protected from spambots. You need JavaScript enabled to view it.
You are here: Home Blogs
Project Management Blog
Blogs

Blogs (1342)

Thursday, 24 August 2017 04:08

Add Green Thinking to Your Procurement Process

Written by
Rate this item
(0 votes)
This content is from the TenStep weekly "tips" email dated 2017.28.08

Add Green Thinking to Your Procurement Process

The TenStep model for sustainable project management (GreenPM®) integrates green thinking (“greenthink”) into every project management process. The point about green project management is not that you make every decision in favor of the one that is most environmentally friendly. The point is that you start to take the environment into account during the decision-making process. You might make most decisions the same as you do today. But there might be some decisions you would make differently.    

Procurement

Procurement refers to the aspects of project management related to obtaining goods and services from outside companies.

Green Procurement

There are a number of areas within procurement that can be enhanced to consider sustainability and help you establish a green procurement approach.

  • Plan Procurements. Green procurement starts with the Procurement Management Plan. The Plan will incorporate green thinking. It is important to understand any organizational Environmental or Sustainability policies and standards you are adopting on your project. As you gather and rank the needs against which you will evaluate vendors, you can now include sustainability criteria that the vendors need to meet. You can also establish the weighting factors for these needs and ultimately rate the vendors on their ability to meet your environmental and sustainability requirements.
  • Obtain Seller Responses. In your RFP, you may include information on your organization’s environmental focus (such as describing your GreenPM processes) and have the vendor comment on how they will align to these, or make a general inquiry regarding the vendor’s use of green processes. Each vendor should be able to explain and demonstrate how they help accomplish your environmental goals, possibly describing how they have completed similar goals previously.
  • Select Sellers. Map the vendor capabilities against your requirements and weighting factors, including the environment requirements that you have established. Using GreenPM, it is possible that your vendor selection may result in a different vendor. For example, if your environment requirements are weighted highly, it is possible that there is a vendor with a significant focus in this area who ends up being your top ranked vendor.
  • Administer Procurements. You should validate that the vendor is performing as agreed throughout the project. This includes confirming that the vendor is following their promised green practices and meeting any defined environment criteria for deliverable completion. Procurement audits can be one approach to validating the compliance to your expected standards and processes.
Procurement is not simple and organizations seek to continually streamline and improve their procurement approaches. Green procurement may add another dimension to improving procurement processes.
At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it.
Rate this item
(0 votes)

396Click Here to Listen to the Interview: http://bit.ly/PMPodcast396
Read More: http://bit.ly/PMPodcast_396

Are you using an adaptive life cycle to manage your projects? You know, something that falls under the general umbrella of Agile like Scrum, XP, Kanban or DSDM?

And if your answer to this question is yes, then think about when exactly you started using these approaches, because that date says a lot about you and your organization. If you started 20 or more years ago then you can consider yourself to be an innovator, but if you started just recently you are a laggard. (And just in case you are wondering, I would put myself in the middle with what is called the "early majority".)

But no matter when you started your journey into Agile it might be interesting to know how many of us out there are actually using Agile on our projects. And according to Joseph Flahiff (www.whitewaterprojects.com -- www.linkedin.com/in/josephflahiff) there are more than you would think.

How many more? He doesn’t have an exact number, but then again nobody knows how many waterfall-based projects there are either. However, studies done on this subject and a number of other indicators lead him to believe that Agile is now the new normal. The number of Agile projects is massive, which is just one more reason to also get started with your PMI Agile Certified Practitioner (PMI-ACP)® Exam Prep

Rate this item
(0 votes)
Let’s face it: keeping on top of project management paperwork can be a big job. There are documents to create, get signed off and updated. And then there’s finding the information again when you need to revise or use it… A project manager is never far away from a document!

What I want to focus on in this article is the process for updating documents and also include some tips for the Project Management Professional (PMP)® exam. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) defines a change request as a formal proposal to modify any document, deliverable or baseline. But does that really mean that you need to do a change request every time you want to add a new risk to your risk log? That would be really time consuming and add a lot of extra administrative overhead to the job of updating project management documents.

It is a question that we hear often from our PMP® exam prep students in the discussion forums. For example, Gunaseelan asked, “What all are the project documents which requires approved change requests to get updated?” Housa            m had a similar question.

In this article we’ll dive into when you need a change request to update a project document and when you don’t.

And unfortunately it isn’t a totally straightforward answer!

What Change Requests Are For

Change requests are there to help you keep control of the document. They ensure that if an important project document is going to change, everyone knows what that change is and how it could affect other project assets.

For example, if you update your Resource Management Plan, that might have an implication for the project schedule or budget.

Change requests bring transparency to this process and also a degree of formality. This can help stop stakeholders asking for lots of little changes; the fact they know they have to go through a formal process might make them think twice!

What The PMBOK® Guide Says

So what does the PMBOK® Guide say about the documents that are subject to this process? Actually, not a great deal.

The PMBOK® Guide doesn’t clarify the documents that require a change request, and equally it doesn’t say which documents don’t require one. It just says “any document” but if you have worked in projects you’ll know that this isn’t what happens in real life.

Change Requests Are Required For Controlled Documents

There is useful guidance in the PMBOK® Guide about the types of documents that we have on projects. This is split between “controlled” documents and everything else – the “non-controlled” documents.

Basically, the Project Management Plan (with all its subsidiary plans and baselines) is considered to be a controlled document, while all the rest are non-controlled documents.

That gives us a handy rule of thumb. If a change would require a modification to any of the Project Management Plan documents (controlled documents), then a formal change request should be issued.

This should be submitted to the Change Control Board (CCB) for consideration and possibly approval. However, if the change would only affect a non-controlled document, such as the issue log (for example, because you were updating it with a new issue), then no change request is required.

However, you will have to exercise your professional judgement. The milestone list, for example, is a project document that might not fall within your Project Management Plan. If a change to a milestone was approved, it would likely require the project schedule to be amended, which would most likely require a change to the schedule baseline, which is part of the Project Management Plan. The Project Management Plan is a controlled document, so that particular change would require a change request.

The trick is thinking through what needs to happen at every stage. While the first document that gets updated might be non-controlled, there is possibly an impact on another document that should also be taken into consideration.

What About The Project Charter?

The Project Charter is not a controlled document and it doesn’t change very often. However, instead of editing the text within the document if you do need to modify it for any reason, you can add an addendum. This is a short section at the back that details the updates or changes within the document.

It’s useful to keep this separate as it gives you the ability to see what has changed from the original Charter.

When You Don’t Need A Change Request

Generally, you don’t need a change request to update a document that is not considered “controlled”, like the Project Charter.

There is also one situation when you don’t need a change request to update your Project Management Plan. That’s when the plan is still being developed. If your plan is not yet approved, you don’t need to get a change request approved in order to modify any part of it. Phew! At this point in the project when you are putting the plan together it is likely to change often, so that’s one less thing to worry about!

The act of getting your Project Management Plan approved is the first sign off for this document, which creates the baseline. Any future changes are effectively deviations from the original document that was approved, and they would need a change request so that the impact can be understood and acted on.

PMP® Exam Questions on Updating Documents

Questions about which documents need to be updated, and which would need a change request, could come up in your PMP Exam.

The correct answer will heavily depend on the question and the context in which the question is asked. Therefore, we always recommend that students make reasonable assumptions based on all the available information in the question. Then select the best answer from the choices given. It will not always be the ideal answer, but it should be the best option from those provided.

Remember to think about the implications of a change on a project. Frequently, if a change request is issued and approved, different types of project documents are likely to be updated. Think of how many times you can see that ‘Project Documents Update’ is one of the outputs from one of the processes – it’s a lot!

Project management documents help to keep your project under control. Managing them, updating them and ensuring the right versions are available to the right people goes a long way to reducing the headaches on a project. Hopefully, these tips will help you manage your documentation, whether a change request is required or not.

About the author: Cornelius Fichtner, PMP is a noted PMP expert. He has helped over 40,000 students prepare for the PMP Exam with The Project Management PrepCast at http://www.pm-prepcast.com/ and he guides credential holders on earning PDUs with The PDU Insider at http://www.pdu-insider.com/
Last modified on Thursday, 17 August 2017 22:52
Wednesday, 16 August 2017 14:48

Use Five Steps in a Comprehensive Training Approach

Written by
Rate this item
(0 votes)
This content is from the TenStep weekly "tips" email dated 2017.16.08

Use Five Steps in a Comprehensive Training Approach

Training is usually provided as the project solution is about to be deployed. However, on many projects the team does not start thinking about training until the end of the project. This is much too late. The key to an effective training approach is to start the planning process early. If you wait to consider training needs until the end of the project, you will not have enough time to do it the way you would like.

Training has a mini-lifecycle of its own. Some organizations call this a "workstream". In other words, training is not project management work. It is done in the lifecycle. There are five main steps. 

1. Start with the strategy (maybe)

First think about whether you need a Training Strategy. You would want the strategy if your project is complex and there is a large training component. All strategy documents on a project are typically done up-front in the Analysis Phase. The strategy includes an understanding of the stakeholders, type of training needed, the desired outcome of the training, assumptions, risks and the overall training approach. 

2. Create an overall Training Plan (for sure)

The Training Plan is created during the Design Phase. If you have a Training Strategy, the Training Plan simply contains the additional details required to make the classes real. If you do not have a strategy, then the Training Plan typically has some initial aspects of the strategy, and then quickly gets into the details as well. The Training Plan would include a description of the classes, number of classes offered, timing, the delivery mode (in-person, virtual, e-class), content development process, etc.  

3. Develop the training content

You develop training content at the same time that you are developing the rest of the solution. Isn’t that a novel concept? 

4. Test the training content (optional)

You can test your training content and delivery in a controlled class delivery. The test training is offered to the internal team, or perhaps to an initial customer group as a pilot test. This serves as a test of the material and helps prepare the instructors so that they will be more comfortable delivering the training to customers.

5. Implementation

The training classes are delivered based on the timing specified in your Training Plan. You should have developed (and perhaps tested) your training content, and you should be ready to go regardless of when the actual training is needed.

Summary

What you see in this approach is that the training process follows a mini-lifecycle. You analyze (Training Strategy), design (Training Plan) construct, test and implement the training. This lifecycle allows you to have all of the components you need as you need them. 
At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it.
Rate this item
(0 votes)
This content is from the Method123 weekly email dated 2017.10.08

Use Two Criteria to Determine Your WBS Estimating Threshold

When you create a schedule you generally don’t know enough to enter all of the detailed activities the first time though. Instead, you identify large chunks of work first, and then break the larger chunks into smaller pieces. These smaller pieces are, in turn, broken down into still smaller and more discrete activities. This technique is referred to as creating a Work Breakdown Structure (WBS).

How small should the activities be before they do not need to be broken down further? This is referred to as your “estimating threshold”. For example, if your estimating threshold was 80 hours, you would continue to break the WBS into smaller entities until all work was less than 80 hours. No work would be left at a higher level.

There are two criteria for determining the threshold.

  • Better understanding the work. If you leave schedule activities at too high a level it may not be clear what is required to complete the work. You need to make sure the work is granular enough that it is understandable and it is clear what is required to complete it. For example, if you assign someone an activity that is 240 hours, there may be a lot of work to do for completion, and it may be confusing. If you assign four activities of 60 hours each (or 6 activities of 40 hours each) it should be more clear what is expected for each piece of work.
  • Better able to manage the work. When you assign work to a team member you don’t know for sure how he is progressing until the due date (or the completion date if it comes first). For instance, if you assign a team member a piece of work that is due in eight weeks, you are not going to know for sure whether the work is on time until the eight-week deadline. Until that time you can just approximate if it appears things are on schedule. However, eight weeks (or longer) is too long to wait to know for sure if the work is on track. A better approach is to break the eight-week activity into four two-week activities. Then you will know after two weeks if the work is progressing on time or not.
Activities that are to be worked on in the distant future may not be able to be broken down less than the threshold because there may be too much that is unknown about the work itself. The future work can be left at a level higher than the threshold. However, if you leave future work at a high-level, it is still critical to break the work into smaller pieces at least two to three months before you need to start executing the work. This is referred to as "rolling wave" planning. 

These two factors – understanding the work and your ability to manage the work effectively - should drive your decision on how small to make your activities.

......................................................
Last modified on Friday, 11 August 2017 16:09

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update

Who's Online

We have 342 guests and no members online

Got something to say?