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

Rate this item
(0 votes)
This content is from the Method123 weekly email dated 2017.19.01

Here Are Three Techniques for Managing Small Scope Changes

Everyone can recognize and appreciate that a scope change request must be invoked for large changes to the project. However, you may encounter resistance to formal scope change management for small change requests. The sponsor and other project team members may consider this to be unnecessary overhead for such small decisions.

They might be right. There are three alternate techniques to employ that may help with small changes. None of these options implies that you are not managing and tracking scope changes. These are just additional techniques to use that may be more appropriate for managing small scope changes. 

  • Batching. It is not always practical to get the sponsor to approve all small scope change requests each time one is requested. It is a better use of time to batch the small changes up into a bundle. This means that you keep track of the small scope changes, their business value and their impact on the project. Then, when they hit a certain threshold, you take them all to the sponsor for approval. For example, instead of visiting the sponsor ten times for small scope changes, you batch the small changes together and see the sponsor one time.
  • Discretion. The sponsor can delegate approval of small scope change requests to a more tactical customer manager. The ability to approve small changes usually assumes that the changes do not make the project exceed the agreed-upon cost or duration. If the project is in any risk of not meeting its cost or duration commitments, this discretion should not be used – even for a one-hour change request. In this case, all changes should go through a normal scope change process (like batching) to receive corresponding budget and schedule relief for any changes.
  • Scope Change Contingency Budget. Your organization may recognize that a certain level of scope change is inevitable and you may be allowed to allocate a percentage of the total project budget to account for small changes. For example, you may have a 5% contingency added to your budget for scope change. If your total project budget was $500,000, your scope change contingency budget would be $25,000 for small scope changes. The customer must rationalize the budget to make sure all important scope changes can be accommodated. If the customer uses the budget up early on small scope changes, there will be nothing left for later change requests. This budget is used for change requests under a certain dollar or hour threshold. Larger requests still go through normal scope change management and be evaluated by the sponsor. 
Even thought these are small changes, they should still go through some type of scope change management. Otherwise you are susceptible to scope creep. 
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 TenStep weekly "tips" email dated 2017.18.1

Should You Implement Time Reporting
for Internal Projects?


Every company that has a consulting or professional services organization is familiar
with time reporting. It only makes sense that if you provide services to customers on a time and materials basis, you need to accurately allocate your time to them. Some
organizations also require time reporting for their internal staff in both the operating units and on projects. It makes sense for some of the exact same reasons it does for external customers.


  • It allows your company to determine exactly where your money is being spent, and allows you to determine if this allocation is appropriate. For instance, you may find that too many of your dollars are being spent supporting operations and not enough is being spent on projects. Or you may find that too many hours are allocated to internal departments (Finance, Human Resources, etc.) and not enough is being spent on the revenue-generating business units.
  • Time reporting allows you to gather more factual information on the specific types of work people are doing. For instance, you may find your accounting staff is spending too many hours on end-of-month closeout, which would motivate you to streamline the process.
  • IT staff can tell how their hours are allocated to business units. The business units will no longer have only a fuzzy perception of the labor being utilized on their behalf.
  • You can track time on projects. Project managers estimate costs and duration based on an understanding of how many hours are needed on the project and how many resources are available to work the hours. Time reporting allows you to compare your estimated hours against the actual hours so that your estimates can be more accurate in the future.
Accuracy is important, but only up to a point. You would like the numbers to be 100% accurate, but if the numbers were 90% accurate it would still be a big win for most organizations. 

Expect Cultural Resistance

The biggest drawback is a cultural one, but it should not be ignored. Generally, people hate to have to track their time. They will tell you it is such a burden - even though it takes maybe 5-10 minutes per week. Implementing time reporting must be recognized as a culture change initiative.
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)

humor 26 Click Here to Listen to the Interview: http://bit.ly/PMPodcast382

Read More Here: http://bit.ly/2jFuMMT

This interview about why Agile might be failing in your organization with NK Shrivastava was recorded at the Project Management Institute (PMI)® Global Congress 2016 in San Diego, California. We discuss his presentation and white paper Top Five Warning Signs That Agile is Not Working for You. Here are the abstract and conclusion:

Abstract: There are good possibilities of success when adopting an agile approach in an organization, but five symptoms in particular serve as warning signs that the organization’s agile transformation is not working well.

The five warning signs include: (a) no signs of value delivery for over 3 months, (b) teams resisting customer changes, (c) teams “waterfalling” sprints, (d) customers foregoing involvement in development and testing, and (e) lack of visibility for agile in the organization. Potential solutions for these problems are also described in this paper. Many organizations can solve these problems internally, but sometimes an external resource such as a change agent or an agile coach is needed. By addressing these issues, organizations can increase the chances of a successful agile transformation.

Conclusion: Agile doesn’t work by itself. Organizations that implement agile with minimal team support and expect it to work perfectly “out of the box” will likely be disappointed. Successful agile adoption depends on factors at the organization and team levels. Organizations need the right mindset, a strong commitment, a culture conducive to implement agile, and the ability to secure resources and outside help as needed. Teams need the training, skills, and empowerment to absorb and implement agile principles. With these factors in place, organizations and teams should be able to build the foundation for agile success.

Rate this item
(0 votes)

This content is from the Method123 weekly email dated 2017.12.01

Five Tips to Create a Work Breakdown Structure (WBS)

The Work Breakdown Structure (WBS) is the first step to create a project schedule. The WBS is used to uncover all the work. Understanding the project work, and the project management work, gives you a total picture of the project.

Use the following five techniques to create a solid WBS for your project.



Do Not Make the WBS Too Tall

If you envision the WBS being built with post-it notes on the wall, it is important that you not let the WBS get too tall (This could also be called "too deep"). Depending on your WBS approach, it may take you two to four levels to get the deliverables defined. The general rule of thumb is that the number of levels for each deliverable should not exceed five and even five might be too many.

Create a WBS Dictionary for Large Projects

Normally a dictionary would not be needed, but if your WBS has hundreds (or thousands) of detailed activities, there may just be too much to keep track of by hand. If the WBS is very large, it might make sense to place all of the important information in a WBS dictionary. Once the WBS information is entered into a tool, the tool can also help to keep track of changes to the work so that you can trace how the change impacts the WBS and the schedule. Having the WBS in a tool also makes the information easier to reuse for future projects.  

Use Your Summary Activities for Schedule Milestones

Summary activities are the ones that are broken down into more detail. Detailed activities are not broken down further. When you create your schedule, you should only include the detailed activities, not the summary ones. For the sake of clarity and readability, it often makes sense to include these higher-level summary activities in the schedule to represent a logical roll-up of the detailed activities. A summary activity that represents the completion of a major deliverable could also be included in the schedule as a milestone.

Break Summary Activities into Two or More Detailed Activities

Since you chose to break a summary activity into smaller activities, it does not make sense to only have one detailed activity under a summary one. If you do, the detailed activity represents the exact same work as the summary activity. This does not buy you anything. If you are going to break work down into a lower level, make sure you always identify two or more items at the lower level.

The Detailed Activities Should be Written as Action Oriented Activities

The detailed activities on your activity-based WBS are ultimately moved to the schedule. For that reason, it is easier if the detailed activities in your WBS are action oriented – just as activities in your schedule would be. For example instead of stating a detailed WBS activity as “conference”, you should state it as “organize a conference”, or “attend a conference”.   

WBS's are interesting structures that serve as the backbone for creating a schedule. There are many more techniques as well, but these five provide a good starting point.  
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)

bestClick here to listen to our Best PM Podcast episode for today: http://bit.ly/PMPodcast_361 

23,918 project managers have listened to it so far!

Leadership in project management is an important topic these days. And if you are like most project managers then you may have fallen into project management a bit by accident. And then, after you have successfully delivered a few projects, suddenly everyone tells you that you must improve your project management leadership skills.

Effective project management, they say, depends a lot on your project leadership.

And so once you realise that you have to transform into a project leader then leadership training will be part of your ongoing professional development, which is where our guest can help.

Niraj Kumar (www.leadproje.com -- http://www.linkedin.com/in/thenirajkumar) is a leadership expert and proponent of self-growth through continuous learning. Together we explore his view on leadership, how these skill help you as a project manager, how they help you when dealing with senior executives, and as always we include a lot of tips on how you yourself can improve how you approach project management and leadership starting today.

http://bit.ly/2a4YVp6 ‪#‎BestofPMPodcast

 

Page 1 of 250

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

Got something to say?