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)

Rate this item
(0 votes)
his content is from the TenStep weekly "tips" email dated 2017.27.09

There Are Three Main Project Organization Types.
Which Are You?


The way that the project team is organized is directly related to the way the entire organization is structured. There are three major organization structures to manage work and people.

Functionally Based

In a functional organization, a project team is generally staffed with people from the same department. For instance, if the project is related to the finance function, the project resources come from the Finance Division.

Another way a project is staffed in a functional organization is by executing portions of a project in separate functional organizations. For example, let’s say that a large project needed resources from the Finance, Purchasing, IT and Manufacturing departments. In a functional organization, the project would be broken down by organizational unit and each unit would do its own part relatively independently. At the end, all of the independent solutions would be integrated into one final solution.  

The biggest advantage of functionally-based projects is that there is usually clear authority, since the project managers tend to also be the functional managers. A major disadvantage of the functional organization is that your functional area may not have all of the specialists needed to work on a project. A Finance project with an IT component, for instance, may have difficulty acquiring specialty IT resources.

Project Based

When projects are large enough, it's possible to form functional departments around the project team. This is especially practical when a large program has hundreds or thousands of people assigned over a long period of time. Advantages include clear authority, since the project manager is also the functional manager, and a clear focus, since everyone on the team has only the project for their primary responsibility.

One disadvantage is duplication of resources, since scarce resources must be duplicated on different projects. For instance, a large project may have its own Human Resources staff, which could duplicate a central Human Resources Department. There can also be concerns about how to reallocate people and resources when projects are completed. In a functional organization, the people still have jobs within the functional department. In a project-based organization it is not so clear where everyone is reassigned when the project is completed.

Matrix Based

Matrix organizations allow functional departments to focus on their specific business competencies and allow projects to be staffed with specialists from multiple functional organizations. For instance, a Legal resource might report to the Legal Department, but be assigned to a project in another department that needs legal expertise.

The main advantage of the matrix organization is the efficient allocation of all resources, especially scarce specialty skills that cannot be fully utilized by only one project. The matrix-based organization is also the most flexible when dealing with changing business needs and priorities.

The main disadvantage is that the reporting relationships are complex since many people have multiple work managers - both a functional manager and one or more project managers. Staff members need strong time management skills to ensure that they fulfill the work expectations of multiple managers.

Summary

The matrix-based organization is the most common. Can you tell which model your organization uses?  

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.20.09

How Do You Handle Projects With
Predetermined End-dates (Timeboxing)?


In a perfect world, your project schedule and completion dates would be derived based on the amount of work to be done and the number of resources available. As you know, that is not always the case. Sometimes when the project is assigned, it already has a targeted end date. For instance, the end-date may be determined by a government regulation, a scheduled event or to coincide with another company initiative. This situation is referred to as a "timebox", meaning you have a fixed amount of time to get the work done and the end-date is “boxed” in.

There is nothing wrong with having a fixed end-date. It can give everyone on the team a sense of urgency and focus. There may be a problem, however, if the project manager and team do not think they can get the work done by the deadline. In that case, the project manager needs to raise this as a risk. Potential risk plan actions include:

  • Assigning more resources to the project. Too many resources may have diminished value but this is usually the first place to start.
  • Having the team work overtime, with the understanding that overtime itself has a diminishing return, and that long-term overtime can actually have a negative effect.
  • Working with the stakeholders to scale back the scope. This may include removing entire deliverables or functionality from required deliverables.
  • Determining whether some required deliverables and features can be delivered later than the due date. For example, a 90% solution may be viable at the due date, with the additional work completed soon after.
Important -  Estimate the Amount of Schedule Risk

Even if your manager or sponsor has given you a fixed end-date, it is important to carefully build the schedule first as if you did not have the fixed end-date. If you do this first, it will give you a sense for how realistic it is to hit the fixed date. For example, let’s say you have a project that has to be completed in nine months. If you first create a “normal” schedule that shows the project will be complete in 9 ½ months, it would not be too much of a stretch to think you could complete the work in nine months. However, if you create a “normal” schedule and it shows the end date at 13 months, you will understand the difficulty and the risk associated with trying to get all of the work completed in the nine-month timebox. This does not mean that you will not have the nine month deadline. However, it gives you more information to have a fact-based discussion on the project risks and options that are available to you.  

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)


398Click Here to Listen to the Interview: http://bit.ly/PMPodcast398
Read More: http://bit.ly/PMPodcast_398

Every project that you and I have ever and will ever manage depends on people’s skills.

The sponsor relies on you as the project manager to successfully lead the team, you rely on the team to have what it takes to create all the deliverables at the required quality, and the end user -- the recipient of what you and the team deliver -- must have the skills to use the product you finally give them.

But what if the skills don’t match up to the tasks at hand? What if a team member is lacking a skill? What if the technology is so new and different that your users will have a hard time with it? The answer is of course coaching, mentoring and training.

And there is no one better than Susanne Madsen (www.susannemadsen.com -- www.linkedin.com/in/susanne-madsen-1134312) who coaches and mentors project managers into project leaders to come on the program and help us understand these three similar yet different activities.

Rate this item
(0 votes)

This content is from the TenStep weekly "tips" email dated 2017.13.09

You Have Heard of Monte Carlo Scheduling.
Here is What is Means


Schedules are the way you estimate the work, resources and durations for your project. One way to manage schedule risk for large projects is through the Monte Carlo modeling. Here is an example to demonstrate Monte Carlo. The example is simple, but it requires some focus for it to make sense.

First, you need to assign multiple durations to activities, along with the probabilities of hitting each estimate. You could assign many durations and probabilities for each activity, but let's keep it simple. Let's say you provide three estimates that represent the best case, most likely case and the worst case. For each of these cases, you also assign a probability of each instance occurring. 

For instance, let's use the following estimates:

  • 20% change of hitting the best case estimate
  • 60% chance of hitting the most likely estimate
  • 20% chance of hitting the worst case estimate
You have to estimate these three numbers for each of the major work activities in your schedule (or all activities if it makes sense). For example, you may estimate an activity to most likely take 10 days, with a best case of 5 days and a worst case of 20 days.

Monte Carlo then looks at every activity in your schedule. The simulation uses a random number generator to select an estimate for each activity - best case, worst case or most likely. After the simulation has run for each activity, the entire schedule duration is calculated.

So far, so good. If we ended there, Monte Carlo would not be so interesting. However, the schedule simulation is then re-run. When the random number generator runs for each activity, differing durations will be assigned to each activity (best, worst, most likely), therefore calculating a different end-date.

The schedule model is run hundreds or thousands of times so that the percentages have a chance to play out. For instance, in the example above, if the simulation was run 1000 times, you would expect that each individual activity would be assigned the best case estimate 200 times (20%), the worst case estimate 200 times (20%) and the most likely estimate 600 times (60%).

As the modeling tool randomly picks estimated values based on probabilities, many different project end dates occur. Some show the project completing earlier since many best case estimates are randomly chosen. Some schedules show the project completing later since more worst case are randomly chosen. However, after running the project model 1000 times, a pattern emerges that allows you to estimate the chances of hitting any end date. 

Now instead of saying "we will complete the project by May 31" you would say "there is an 80% likelihood we will complete the project by May 31". If your sponsor wants the project completed by April 30 instead, you can look at your simulation and state "there is only a 45% likelihood we can complete the project by April 30".

Monte Carlo gives you the range of possible end dates and the probability of achieving them.

Kind of interesting isn't it? 

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)

397Click Here to Listen to the Interview: http://bit.ly/PMPodcast397
Read More: http://bit.ly/PMPodcast_397

There is no doubt in my mind that you have heard the term lessons learned before.

It is mentioned extensively throughout A Guide to the Project Management Body of Knowledge, (PMBOK® Guide), I teach it as part of my Project Management Professional (PMP)® training lessons and my favorite search engine gives me over 51,000 results for the search term “lessons learned in project management”. In fact, as an experienced project manager you have probably participated or even chaired one or two lessons learned meetings yourself on your own projects.

But let’s consider the bigger picture around lessons learned. What process do we follow? What management techniques are there for lessons learned? Are all documented lessons learned equally valuable?

These questions need answers. And so I’m happy to welcome Elizabeth Harrin (www.girlsguidetopm.com -- www.linkedin.com/in/elizabethharrin/ - ) who has the answers for us!

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?