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 (1316)

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
Friday, 11 August 2017 00:43

Five Important Things to Know About Critical Path

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

Five Important Things to Know About Critical Path


Some people think the critical path is where the critical work is performed. Similarly, it was just a few weeks ago that a project management stated that she needed to pick the "right" critical path for her project. Both of these definitions are incorrect.

Critical path refers to the longest path through the schedule and represents the shortest time it takes to complete the project. The work on the critical path might or might not all be "critical". The critical path is determined by the work and the dependencies of your schedule. You do not pick the "right" critical path.

The critical path is an important aspect of your project schedule. Here are five things to know about critical path.

1. Float refers to schedule flexibility

On every project, no matter how complicated, there are always some activities that can be started earlier or completed later without jeopardizing the final completion date. This flexibility between the earliest time an activity CAN be completed and the latest time when it MUST be completed is called "float".

2. The critical path has no float

Now let’s look at those activities where you do not have the flexibility in the start and end-dates. These activities cannot be completed earlier because they are pending the completion of another activity. They also cannot be completed later without causing all the succeeding activities to be late. All of these activities back up tightly against other activities that precede or succeed them. In other words, the critical path has zero float.

3. The critical path is the longest path

The various network paths in your schedule have various lengths. The longest path is the critical path. Since it is the longest path, every other path will, at some point, have to wait while the critical path work is completed. This "wait" time is the float.

4. You need to understand critical path to manage the project with precision

If the project is trending late it is very important to identify the critical path activities. Unless you are able to accelerate activities on the critical path, the end-date for the entire project will not change. Applying additional resources to activities that are not on the critical path will not affect the overall project end-date. Your chance to make an impact on the projected end-date relies on your ability to identify and shorten the critical path.

5. The Critical Path May Change

Given that there are many, many paths through the schedule, it’s possible for the critical path to change. For instance, say you have a project with a critical path (longest path) of 22 activities over nine months. Let’s assume that there is another path of work that has 19 activities and takes 8 ½ months. There are two weeks of float on this path. Let's say one of the activities on the 8 ½ month path ends up taking an extra four weeks. Because there was only two weeks of float in the path, it will now become the critical path and force the entire project to complete in 9 1/2 months.

You will not be able to calculate critical path unless you are sequencing all activities. However, all project managers should understand this concept - even if you are not able to actually calculate one for your project. 
Page 1 of 264

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 360 guests and no members online

Got something to say?