You are here: Home Blogs Displaying items by tag: Project Manager
Project Management Blog
Tuesday, 07 July 2015 19:43

Was Your Project Really Successful?

You have all read the stories about the large number of IT projects that fail. Depending on the report you read, half or more of these projects fail - perhaps as high as 80%. According to the reports, the larger the project, the greater the chance that it will be a failure.

Let’s assume that the number of failed projects is 50% - a low number. What is interesting is to try to relate that number to personal experience. Where are all of these failed projects coming from? Can you say that half or more of the projects that you managed were failures?

It’s All in the Definition

The idea of a failed project starts with understanding the definition. You may have a perception of what it means to manage a failed project. Your company should have a definition as well, and if they do, your definition should be the same as theirs. One major concept that plays a key role is the idea of tolerances.

Define a Reasonable Cost and Duration Tolerance Level

If you estimate a project to cost $230,000, is your project a failure if the actual cost is $230,500? You missed your budget, right? Yes, but this gets into the concept of tolerances. If you delivered within $500 on a $230,000 budget, you should be lifted on someone’s shoulder and paraded around the company as a hero.

Your company needs to establish the tolerance level that they consider to be reasonable for projects. For example, the tolerance level may be -10% to +5%. That is, if you deliver the project for 5% over budget, it is still considered a success. For the $230,000 project, that means you could have gone overbudget by $11,500 and still have been considered successful. On the other side, if the final cost was underbudget by greater than 10%, that is a problem too. The problem is that the company wanted to deliver projects within expectations. If the sponsor had known that the project actually cost a lot less than estimated, they may have been able to make other decisions with the unused budget. The cost estimate should also include any formally approved scope changes. If your original budget was $200,000, and the client approved an additional $30,000 in scope changes, then $230,000 is the number that you get held accountable for, plus your tolerances.

Normally there is some room for tolerances with your deadline as well. If the projects are internally focused, the end dates are in many cases arbitrary. Your original deadline must also be extended if scope changes were approved.

Declaring Success From a Project Perspective

Once you understand your tolerances (if any), you can start to evaluate success from a project perspective. Generally, the project team members can declare success if:

  1. The project is delivered within the estimated cost, plus or minus the tolerance.
  2. The project was delivered within its deadline, plus or minus the tolerance.
  3. All of the major deliverables were completed. (Some minor ones, or minor functionality, might not be delivered.)
  4. The overall quality is acceptable. (It does not have to be perfect.)
Some companies also look at whether the project team was easy to do business with. That is, did the client and the project team work well together? Was there good communication? If the client had another project (and a choice), would they ask you to work on it again?

Declaring Success from a Company Perspective

Declaring success from a project perspective is normally what is required of the project team. However, from a company perspective, success would also be based on whether the company received the value that was promised from the initial ROI calculations. If the project was a failure from a project perspective, it is normally a failure from a company perspective as well. (Although this is not always the case.)

However, there are many examples of projects that were successfully delivered, yet are not delivering the value promised. If the project team delivered successfully within tolerances, there is usually nothing else that can be done from their perspective. However, it is possible that the return on investment calculations were faulty, or the marketplace was misjudged by the client and sponsor. It is also possible that this project was part of a larger initiative. Although your project may be successful, the overall, larger initiative may be a failure.


Every organization should have some general rules about how to declare overall project success or failure. Your project isn’t a failure if you miss the budget by a dollar and deliver a day late. Normally a project will still be considered successful if it delivers within cost and deadline tolerances, and delivers all major deliverables within acceptable quality. From an overall business perspective, another set of questions should also be answered as to whether the business value was achieved as promised.

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 or contact us at
Published in Blogs
By definition, all projects end at some point. Some may be very long and it might seem like they will never end, but they always do. Two fundamental characteristics of a project are that they must always have a start and an end.

There are a number of things that should happen as the project is nearing completion, or very soon after the official end date. These can vary depending on the project and the standard processes of your organization. It is the responsibility of the project manager to build project termination activities into the project schedule. These should be seen as vital parts of the project, not an afterthought as the team is being disbanded. Some of the activities to consider at the end of a project include:

  • Declaring success or failure
  • Transitioning the solution to support
  • Archiving the project files
  • Conducting performance reviews
  • Reassigning the remaining project team members
  • Holding project conclusion meeting
The project conclusion meeting is a time to reflect on the project that was just completed and see what can be learned that will help the team members and other project teams in the future.

The Project Conclusion Meeting

It is a good practice to start your project off with a formal kickoff meeting to signify that the initiative has officially begun. Likewise, the project should officially end with a project conclusion meeting. If the project had major problems, or if the project was cancelled, sometimes these are called project post-mortems. There is a value to be gained from this meeting, whether the project was a success or failure (or something in between).

There are a number of ways to plan the meeting so that it is as effective as possible. These include:

  • Using an outside facilitator. Many times the group is more comfortable if there is a meeting facilitator from outside the team. This is especially true if the project experienced problems. You can get a more truthful discussion if the facilitator does not have a stake in the outcome.
  • Make sure everyone knows the purpose of the meeting. This can be communicated clearly ahead of time to all of the participants.
  • Send out an agenda ahead of time. Your time will be better spent during the meeting if everyone is prepared ahead of time and knows the discussion topics.
Everyone needs to perceive that they are all there to learn, both individually and collectively.  This meeting is not a performance review. All participants need to feel safe to expose what they did and thought so that they can learn how to be more effective in the future.  

Focus First on What Actually Happened Versus What Was Expected

You won’t discover what to improve unless you know what you achieved and did not achieve versus what you originally wanted. First, have a frank discussion to list what should have happened on the project. For each statement, add a corresponding statement regarding what actually happened. You are not only looking for problems. If there are important events that actually happened as planned, note them as well.

If the project had problems, it’s easy for the discussion to become negative. However, try to keep the discussion positive. Even if the comments come out in a negative fashion, they can usually be crafted into a positive statement. For instance, a negative statement might be "The team never accomplished anything when Sam was a part of the meeting." A more positive statement could be "We had a hard time focusing in team meetings." This reflects the outcome and does not make any judgments as to whether Sam was a problem.

If different people have differing views of what happened on the project, try to find common ground for consensus. Remember there is not necessarily a right or wrong. We are trying to gather perceptions. It will help if people focus on the activities they actually participated in, rather than guessing about activities they were not involved in.

Ask Why

After you list what actually happened on the project, prioritize a smaller number of important areas to focus on further. For each of the remaining items, start asking why they turned out as they did. In some cases you may be focusing on areas that did turn out as you expected. There can be important learning from these events as well.

Lessons Learned for Future Projects

To really be effective, the discussion now needs to be translated into general observations and key learnings that the group can use as lessons for the future. The unique set of circumstances that caused events to happen as they did on your project may not occur again. However, the team should be able to generalize what happened on this project into a set of lessons that can be applied to many projects in the future. These lessons learned should be documented formally and distributed back to all team members. If you have a group (such as a PMO) that keeps a repository of project lessons learned, these insights should be forwarded there as well.

As "lessons learned," the insights are of most interest to the project participants and to others who embark on similar projects in the future. As the PMO receives many sets of "lessons learned," the PMO may also be able to come up with a smaller list of organizational "best practices" that will be of help to all projects in the future.


The end of project meeting is a great opportunity to formally wrap up the project. In addition to signaling that the project is completed, it is also a time to reflect back and see what lessons can be learned for the future. You don’t want to discuss lessons learned right away. Instead, describe what you wanted to happen, what actually happened, and why. Then you have the context to start talking about what lessons you can take forward. The project team can internalize the lessons learned and apply them to future projects. The lessons learned from all projects can also be consolidated at an organization level to develop a smaller number of best practices that can be applied to all projects. This allows the entire organization to take advantage of these common lessons learned.

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 or contact us at
Published in Blogs
When the idea for a project first comes up, you rarely know exactly all the resources you will need. As the project initially progresses, however, you start to define the scope, assumptions, deliverables, approach, etc. This gives you enough information to put together an initial estimate of the effort and other resources required for the project. From there you estimate the duration and cost of the project, gain approval and begin the work.

As you know, the estimates that you prepare up-front are just that – estimates. The only time you know for sure what the effort, cost and duration of the project are is when the project is over. Up to that point, you are dealing with some level of estimating uncertainty and risk.

Estimating Contingency

So far, this is nothing new. All projects have some level of uncertainty. If possible, you account for the estimating uncertainty through the use of a contingency budget. If you believe your estimates are 80% accurate, you could request a 20% contingency budget. For example, if your project was estimated to cost $100,000, you would request an additional $20,000 contingency budget to cover some level of estimating inaccuracy and account for activities that are clearly in-scope but that you may have missed in the original estimate. Any money remaining in the contingency budget is returned to the client at the end of the project.

Planned Reserves

The nature of some projects requires that the project manager take this contingency even further. On some projects, you must actually plan for what the contingency resources look like and how you will get them when needed. You need a strategy and plan for having reserve resources available when needed. These could be labor or non-labor resources, such as hardware, equipment or supplies.

There are a few scenarios where you need to plan ahead for reserve resources.

Time is of the Essence

In a typical project, if you find that work is taking longer than you anticipated, you would ask for additional time and budget. However, if the deadline date is critical and cannot be moved, you may not have time to look for new resources when you first realize you need them. You may need to have a plan already in place for where the resources are and how to acquire them. For example, let’s look at the YR2K projects of the 1990s. If you were entering the final six months of 1999 and had a lot of work remaining, chances are you would have had a game plan for completing on time, plus a plan on how to acquire additional people if necessary. Having internal employees identified and in reserve would allow you to move quickly if you determined more resources were necessary.

High Incremental Costs of Obtaining Resources

You may have resources that are less expensive when purchased in bulk, but very expensive when purchased incrementally. For instance, if the solution you are building requires new hardware, you may find that the price per unit is less as you purchase more units. Let’s say that you estimate you will need 100 units. Depending on your estimating uncertainty, you may choose to purchase 110 instead, and have ten units in reserve. You would do this because the price to purchase the extra ten units now (as a part of the bulk order) is much less expensive that having to purchase ten units later, when the incremental cost would be much higher.  

Long Lead Times for Specialty Resources

Sometimes there is a long lead-time to acquire hard-to-find specialty resources. You may need to have them in reserve if needed. For example, you may work with consulting firms ahead of time to find specialty resources, such as experts in some obscure tool, with the understanding that the requirement is not 100% firm. The firms can work ahead of time to locate these people and try to have someone available on short notice in case you need them later on the project.

Creating a Reserve Plan as a Part of the Risk Plan

Use the following steps to identify the need for reserves and have them ready when needed.

Recognize the need. The first critical step is simply to understand that you have a need for reserves. If you do not recognize that you are in this situation until the need arises, it will already be too late to react. The need for reserve resources will typically come out as part of your risk management strategy. You may have identified a certain project risk and determined that the way to mitigate the risk is to have certain resources in reserve.

Determine the costs and benefits. There is obviously a benefit to having potentially necessary resources in reserve. There is usually a cost as well. For instance, there is the project management time required to put together and execute the Risk Plan. However, many times there are also additional project costs. Let’s look at the three prior examples.

In the YR2K example, there may not have been an incremental cost associated with identifying additional resources if they were internal to the company. The cost would have only been incurred if the resources were needed.

In the second example, you purchase an extra ten hardware units and have them in reserve. The cost to the project is increased by those additional ten units. If you end up needing the units, there is no additional cost. (In fact you probably saved some money.) However, if you don’t use them all, the remaining units may be unused and would be an extra cost that the project would not have had to spend otherwise.

In the third example, you ask consulting firms to look for a specialty resource. You would typically not have an incremental cost up front, unless you paid a consulting firm to have people available and in reserve. However, if you ended up needing an additional resource, the billing rate will probably be higher to reflect the additional work that the consulting firm invested.

Gain approval. The risk, cost and benefit information should be taken to the sponsor for approval. You want to be sure that the sponsor agrees that your reserve plan is rigorous enough to reduce the risk to the project. You also want to make sure the sponsor approves any cost to the project and is aware of any incremental costs if the reserve resources need to be acquired.

Manage the Risk Plan. The activities associated with the Risk Plan need to be moved to the schedule and managed proactively. The project manager should also re-evaluate the risks on a scheduled basis, probably monthly or at the end of major milestones, to ensure that the reserves are still necessary and provide proper risk protection to the project


On most projects, if you find that you need more resources, you talk to your sponsor and revise the budget and schedule if necessary. However, on some projects you do not have the luxury of additional time. In those cases, the project manager must identify where the project may be at risk and have a plan in place to make sure resources are in reserve if needed. Sometimes you actually need to have the resources physically available. Other times, you just need to know that you could acquire them on short notice if necessary. The need for project reserves would typically be identified and managed through the risk management process, with reserve resources being a response to a specifically identified project risk.

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 or contact us at
Published in Blogs
Obviously your project is in trouble if you are missing deadlines and consistently exceeding the estimated effort and cost to get work done. However, you may have a project that actually appears to be on schedule, yet you are concerned about potential problems down the road.

There are things that you can look for that will give you some sense as to whether there are potential troubles lurking. At this point you can’t really call them issues or problems, but they can be identified as risks that have the potential to throw your project off in the future.

Are You Falling Behind Early in the Project?

Many project managers believe that if they fall behind in a project early on, they can make up the time through the remainder of the project. Unfortunately, there is a natural tendency to fall behind as the project progresses. First of all, the more distant you look, the less accurately you can estimate. Second, there are always unexpected items that come up during projects. It is a good idea for project managers to try to get ahead of schedule early on in the project with the expectation that they will need the extra time later.

If you find that you are falling behind early in the project, your best remedy is to start developing corrective plans immediately. Don’t sit back passively and hope you can make the time up later. Be proactive instead, and put corrective plans in place today to get back on schedule.

Are You Identifying More and More Risks?

We are trying to identify warning signs that a project may be in trouble, even though it appears to be on schedule. If you have a multitude of issues that you are addressing today, you probably are not on schedule. However, you may be fine now, yet face a number of identified risks in the future. Of course, all projects have some future risks. However, if you see more and more risks as the project gets going, this could be a big warning sign that your project is in trouble.

If you face this problem, the good news is that you are identifying risks while there is still time to address them. Even if you have an abnormal number of risks, you may still be okay if you really focus on managing them successfully.

Customer Participation Starts to Fade

Your customer needs to be actively engaged during the planning process and the gathering of business requirements. If you cannot get them excited about participating during this timeframe, then you are really in trouble. However, many times the customer begins to become disengaged when the project is a third completed and the project work starts to turn more toward the internal project team. It is important to keep the customer actively involved. The project manager needs to continue to communicate proactively and seek the customer’s input on all scope changes, issue resolution, and risk plans. The customer also needs to be actively involved in testing. The project manager needs to make sure that the customer stays involved and enthusiastic. Otherwise testing and implementation will be a problem down the road.

Morale Starts to Decline

On the surface, if you are on schedule, there is no reason for morale to be going south. If you detect that this is happening, it could be a sign that you are in trouble. You need to determine the cause. Morale might be slipping because people are being asked to work a lot of hours to keep the project on track. That would tend to be an indicator of trouble in the future. It is also possible that the team may think the future schedule is unrealistic. In any case, poor morale needs to be investigated and combated.


One of the important responsibilities of a project manager is to continually forecast into the future to update the schedule, identify risks, and manage expectations. A project that seems on track today could have major problems tomorrow. Keep your eyes open for these warning signs that things are worse than they appear. If you recognize them ahead of time, they can all be classified as project risks, and can be managed and controlled in a manner that will allow your project to succeed.

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 or contact us at
Published in Blogs
Why is it that most of us don’t have a problem working 70 hours a week taking care of our customer’s needs, and yet we have difficulty writing a decent status report? There are two major problems. First, some people do not have great written communication skills, and they are not comfortable writing. However, in most cases, the problems with communication are not a lack of skills, but a lack of focus. Many project managers do not appreciate the value of communicating proactively. When they do communicate, it tends to be short and cryptic, as if they are trying to get by with the minimum possible effort.

Keep the Reader in Mind

The key to communicating is to keep the receiver as the focal point – not the sender. Try to think about what the receiver of the communication needs and the information that will be most helpful to him. If you are creating a status report, put in all the information necessary for the reader to understand the true status of the project, including accomplishments, issues, risks, scope changes, etc.

In many organizations, the project manager needs to communicate with people at multiple levels. If so, remember that a one-size-fits-all approach may not apply to communication. You may need to modify the communication content between managers and executive managers. For instance, you may send a one-page report to your direct manager and major clients showing the project status and financial situation. This may be summarized to a half-page or even one paragraph for executive management.  

Include Useful Information - Not the Mundane

Try to focus the status reports so that the information in them can be used in the decision making process. Ask team members (and yourself) whether the information on the status report is there to communicate something valuable, or if it is just taking up space. With that in mind, what types of information should be included?

Typically the status report should include the following information:

  • Project name / project manager / time period / project description: This is all basic information that needs to be included each time so that people know what they are reading.
  • Overall status indicator: Typically there is a very short indicator that reflects the overall status of the project. A common way to express this is with color codes such as green (on track), yellow (caution), or red (problems).
  • High-level status summary: The top portion of the report should provide summary information regarding the overall project. Make sure that the questions are worded in a way so that a project that is on-track will answer either all 'yes' or all 'no'. Notice that the questions are focused on the present and future state of the project – not the past. For instance:Comments: Provide more information for any questions above that were answered negatively'.
    • Will the project be completed on time?
    • Will the project complete within budget?
    • Will the project deliverables be completed within acceptable quality levels?
    • Are scope change requests being managed successfully?
    • Are project issues being addressed successfully?
    • Are project risks being successfully mitigated?
    • Are all client concerns being addressed successfully?

Significant accomplishments this period: List major accomplishments from the previous reporting period. If the planned accomplishments from last period were not completed this period, the project manager should provide reasons as to why.

  • Planned accomplishments for next period: List major planned accomplishments for the next reporting period.
  • Additional comments or highlights: Describe any other comments that the reader should know that would not be reflected in the status report in the previous fields.
  • Attachments: There are many other project management reports that might be of interest to the reader. Again, make sure to remember your audience. For instance, the project schedule might be of interest to some of your readers, but is probably too much information for everyone. Likewise, your readers are probably interested in summary financial information, but not at a detailed level. Other potential attachments include the Issue Log, Scope Change Log, project metrics / statistics, earned value reports, and any other reports required by your company.
Focus Forward

If you are on a support team, your status reports are going to focus on the prior period up to the present time. That is because support is typically reactive and it is hard to know what you might encounter in the future. However, a project status report should focus more on the present and the future. Prior deliverable accomplishments are of some interest to the reader; however, they are more interested in what it will take to complete the project.


Writing good, effective, and objective status reports requires focus and diligence on the part of the project manager. The purpose of the status report is to communicate the true nature of the project – not how you wish it was. When you write a status report, include information that is of value to the readers and will help them understand what is going on. If there are issues or risks, they should be communicated as well. If your status report is too short, or at too high a level, the reader will not fully understand the status and may have to ask follow-up questions. Creating your status report allows you to keep everyone informed about the true status of the project at a particular point in time. Make sure that you communicate effectively so that the readers have an accurate understanding of the project.

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 or contact us at
Published in Blogs
It should normally be clear that training will be provided when the project solution is about to be deployed. However, what typically happens is that the work associated with training is also all pushed toward the end of the project. The result is that you may feel rushed to create the training material, and the training might not seem as effective as you wanted.

The key to effective training, as it is with other aspects of the project life cycle, is to start the planning process early. If you wait to consider your training needs until the end of the project, you will not have enough time to do it the way you would like.

Start with the strategy (maybe)

The first possible deliverable to consider is a Training Strategy. You would want to consider this level of planning if your project is complex and there is a large training component. For instance, if you are involved in a project to implement a new Customer Relationship Management (CRM) application, this type of application obviously has a dramatic impact on the Sales and Marketing users. You may want to create a Training Strategy first to make sure you have an agreement with the customer on the overall direction and approach to take.

All strategy documents on a project are typically done in the Analysis Phase. So, early on, as you are getting your business requirements, you also get requirements for the necessary training. These requirements are used to create an overall strategy, which should then be approved by the customer.

As you probably know from experience, most projects do not have such a complex training situation, and so the Training Strategy document is not needed for most projects.

Create an overall Training Plan

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 strategy real. If you do not have a Training Strategy, then the Training Plan typically has some initial aspects of strategy, and then quickly gets into the details. The Training Plan would include a description of the audience you are trying to reach (this could include customers and IT staff), an overview of the training needs, and s plan for how you will satisfy the needs. You also need to define how the training will be developed and executed, as well as when the training will be deployed. Remember that training does not only imply stand-up, internal classes. You may consider bringing in outside trainers, using vendor classes, coaching sessions, webinars, how-to instructions, frequently asked questions, computer-based training, etc.

Develop the training content needed

If you complete the planning documents ahead of time, you will be ready to develop the training content at the same time that you are developing the rest of the solution. The Training Plan is not a schedule,.so you will need to add the remaining development and deployment activities to your schedule. However, at this point the confusion has been lifted and it should be clear what has to happen in the training arena.

Test the training content, if necessary

In most instances, the first time you deploy training is actually in a live environment with real users. However, sometimes the training is offered first to an internal group, or even the project team. This serves as a test of the material to make sure that it flows well. It also helps prepare the instructors so that they will be more comfortable delivering the training to the end users. If you are going to hold webinars or any other type of distance learning, you can test the technology and the delivery at this time.


It was mentioned earlier that you typically want to train your users right before the solution is implemented. However, this is a generalization. Actually, the training deployment is based on the timing specified in your project Training Plan. However, what you should notice is that this approach reduces the chance that your training will be rushed, or that your training will somehow miss the mark. Assuming you followed the prior steps, at this point in the project you should have developed (and perhaps even tested) your training content, and you should be ready to go regardless of when the training is needed.


What you see in this approach is that the training delivery also follows a life cycle. Just as you do not want to jump straight into your project Construction Phase, you also do not want to wait to the last moment and then quickly jump into building the training content. Some up-front planning is the key, as well as making sure that you do any construction of training content at the same time that you are constructing your solution. Just as you ensure that the implementation of your final solution will go smoothly, you can also ensure you will have a smooth training deployment by using this structured approach.

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 or contact us at
Published in Blogs
Traditionally, risks represent potential events or circumstances that exist in the future that could have a negative impact on your project. They are not problems today (if they were, they would be issues, not risks), but they have the potential to become problems in the future. On the other hand, they are not definite problems. There is a chance that the risk will occur, but there is a chance it will not. Identifying the risks that you need to focus on is a combination of identifying the risk event, determining the potential impact to your project, and determining the probability that the risk event will actually occur. When you are done with this exercise, you look for high-risk events and put together a plan to deal with each one.

Let’s take an example. Say you have a supplier that you are counting on to provide raw materials to build a prototype. However, the supplier has a union contract that is expiring in the next 60 days. There is a risk that the supplier will have a strike that will disrupt shipments. You need to identify this as a risk, estimate the probability of occurrence (perhaps this will increase or decrease over time), determine the impact to the project if it occurs, and then put together a plan to minimize the impact on the project if it occurs.

Is risk always a bad thing?

Now let’s get to the concept of positive risk. After all, isn’t everyone supposed to be an intelligent risk taker? Isn’t it right to push the envelope? Isn’t it better to have tried and failed than to have never tried at all?

These statements get to a difference between how risk is typically identified from a project management perspective, and how it is utilized in culture. The concept of risk in language is broader than how it is typically used in project management. This broader definition takes into account the concept of positive risk, or opportunity risk.

Positive risk

Negative risks are potential future events that could impact your project negatively. In general, they are to be avoided (although there are different risk strategies, depending on the individual risk). Positive risk, on the other hand, refers to risk that we initiate ourselves because we see a potential opportunity, as well as a potential for failure. This is what we are referring to when we say that we are intelligent risk takers.

New technology may provide a good example. Say that you have a software development project that is scheduled to take 90 days to complete. Your business client would rather the project be delivered earlier, and would get more value if it were delivered earlier, but they understand that 90 days is how long the project will take.

One of your team members has an idea. If you utilize a new software-testing tool, it is possible that you can deliver the project in 60 days instead of 90 days. If this were a guaranteed solution, you would jump on it. However, there is risk, since it is the first time you have used the tool. There is a lack of expertise and a start-up learning curve. It is possible that if the tool does not work out, the project could end up taking 110 days to deliver. What would you do?

Of course, you don’t have enough information to make the decision now. However, this example illustrates the concept of opportunity risk. The business client will accept delivery in 90 days. If you decide to use the tool, it is a risk you are introducing yourself, based on an evaluation of the chances of success and the impact of success, versus the chances of failure and the impact of that failure. When it is said that we are intelligent risk-takers, it is these types of decisions that are being addressed.

The debate is on

Even though you may commonly think of project risks as having a negative connotation, you can also use risk management to identify and quantify potential positive risk. If you would be the one introducing the risk, the risk management plan would be within your control. You and your client can determine if you want to accept the risk after understanding the risk plan, the chances of success, the payoff if you are successful, and the impact if you are not successful.

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 or contact us at

Published in Blogs
Tuesday, 16 December 2014 15:17

Allocating Resources in a Matrix Organization

In large organizations, or on large projects, you may have the luxury of full-time resources for your entire team. However, in many (or most) situations, the project manager must utilize shared and part-time resources to complete the work. Some resources may be working on multiple projects, while other resources may also be working in support (or operations) roles. The process of gaining and retaining resources in this environment can be difficult, and is partly the result of how your organization is structured.

Let’s look first at the three basic organizational structures - functional, project, and matrixed. In a functional organization, people are organized into functional specialties such as the Finance Department, Marketing Department, and Information Technology Department. Projects are staffed with people from within the organization. Generally, your functional manager is also responsible for the success of the projects.

In a project organization structure, the people are all aligned around major projects. For instance, you may have an organization built around the building and deploying of a weapons system for the Department of Defense. All the people that are required for the project to be completed are assigned full-time to the project. This might include IT, manufacturing, procurement, finance, etc. The overall project manager is the functional manager as well.

The third option is a hybrid of the two – the matrix organization. People are assigned full-time to a functional organization, but can be temporarily assigned full-time or part-time to a project as well. In this case, the functional manager may be responsible for part of a team member’s workload, and a project manager may be responsible for assigning the work associated with the project. The matrix is especially efficient if your project does not need a full-time commitment from people in the supporting organization. These people can be used part-time on projects. (They may be working on enhancements, but these fit the definition of small projects.) A matrixed organization also works well when your projects are smaller and do not necessarily need full-time resources.

The matrixed organization can be the most efficient at utilizing and leveraging people’s time and skills. However, it only works if the functional manager and project manager (or multiple project managers) recognize the challenges and work together for the company’s overall benefit. The two areas to focus on are planning and communication.


In a matrix organization, it is important to maintain a planning window of upcoming projects and an estimate of their resource needs. If your staffing requirements fluctuate a lot from month to month, or if the projects cannot be forecast many months in advance, you can at least plan using a three-month rolling window. You should then update and refine the plan on a monthly basis. The closest month should be pretty firm. Two months out should be pretty close. Three months out and beyond is best guess.

On the other hand, if the projects in your organization are typically longer, and your staffing plan is well understood, you may want to maintain a three quarters (nine month) planning window and update the plan every quarter. The planning process should include the appropriate project managers and functional managers who tend to share a common pool of resources.


After the planning comes the proactive communication. Remember that in a matrix organization, project managers need resources to do their work, but they do not own them – the functional managers do. So, the onus is usually on the project managers to make sure that the resources are available when they are needed, and that there are no surprises. For instance, if you and the functional manager agree that a specific set of people will be available for one of your projects in two months, don’t just show up in two months and expect them to be ready to go. In fact, you should expect that they will not be ready if you have not communicated often and proactively. The project manager should gain agreement on resources two months in advance. The resources should be confirmed again at the next monthly staff allocation meeting. The project manager should double-check resources again two weeks before the start date, and follow-up with a reminder one week out. You are much more likely to have the resources available when you need them if you take these proactive steps.

Planning Tools

Secondary to getting a good planning and communication process in place is worrying about a tool. There are resource allocation tools on the market, but for small to medium organizations a good spreadsheet will work fine as well. The spreadsheet might have people down the rows and work across the columns (or visa-versa). Each month (or quarter) could be on a separate tab in the worksheet. For each month (or quarter), you plan the projected work allocation for each person, ensuring that all work is adequately staffed, and that all of your resources are fully engaged.

For larger organizations, a specialized resource/workload planning and tracking package may be appropriate. You can also document a skills inventory for each person so that you can see who might be a potential fit for projects coming up in the future.


Many companies and organizations struggle trying to optimize the people allocation in a matrix organization. You can get software to help make this easier. But software is just a tool. Overall staffing success in a matrix organization depends on having good planning processes in place, maintaining a partnering relationship between the project managers and functional managers, and communicating proactively and effectively.

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 or contact us at
Published in Blogs
Tuesday, 02 December 2014 19:43

When to Implement a Requirements Freeze

There are different opinions about when to implement a requirements freeze. When considering a freeze, it is important to keep the following facts in mind.

You Cannot Freeze Business Change

Business is always changing, and the project solutions that are built must reflect these changes. However, you can still freeze change requests. Freezing change requests is simply a technique to bring closure to the project. Remember that when you build a solution for your client, the project only represents the initial steps in the product lifecycle. Once the system goes into production, there may be follow-up phases to the project, or the solution will go into a support and enhance stage. This stage could easily end up representing ninety percent, or more, of the entire solution lifecycle. The enhancement process is the way that the application is changed over the long-term. So, do not seek to freeze business change overall, only to freeze changes that would extend the life of the initial project. If changes are needed after the project freeze is implemented, they go on the backlog to be addressed later as enhancements.

All that being said, you do not want to deliver a solution that does not meet the business needs. That would not make sense either. If you implement a requirements freeze, you must also have a process in place for getting around the freeze. What you are really doing is gaining agreement with the client sponsor to raise the threshold for scope change management. During the freeze, for instance, it may be that all change requests need to be approved by the sponsor personally. If the sponsor understands the benefit of the change request, as well as the cost and impact to the project, he may still approve the request if it is important enough. However, even important changes may not get approved during the freeze. What may happen instead is that the change will be prioritized high as part of an enhancement request after the solution goes live.

Fixing Errors is not Affected by the Requirements Freeze

You may wonder whether system testing is the right time to implement a freeze. Remember that the freeze is on business requirements changes. Of course, if you find problems or errors in the system test, they need to be corrected. System testing is a time when you do stress testing, usability testing, documentation testing, performance testing, etc. As an example, during requirements testing you may find that you misinterpreted a requirement, which will require a change. This is not a change to the requirements, but the correcting of an interpretation error. This may be allowed. During stress testing, you may find that your hardware is not powerful enough to take the load. This may require changes to the system configuration, or a change in how the transactions are processed. Again, this may be required under the freeze.

However, hopefully your client is not adding new business requirements during system testing. When you get to system testing, in many cases you have to retest when changes are introduced. For instance, if a change request is allowed during system testing, you must make the change, unit test it, run integration tests, and potentially rerun all the system tests. This is very disruptive, and if possible these changes should wait until the enhancement process after implementation. In fact, at this point in the project, you may even defer some errors that were uncovered during testing if they do not have a major impact to the value of the solution.


If you consider implementing a requirements freeze, it shows that you have recognized that continued change requests will jeopardize your ability to deliver within your budget and deadline. You can then come to an agreement with your sponsor to allow the team to focus on a fairly stable system for completion of the testing and implementation process. Critical change requests are still allowed, while less critical changes are deferred until after implementation, during the enhancement process.

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 or contact us at
Published in Blogs
Many people work in competitive bidding environments, where the company generates revenue by winning contracts to complete projects and deliver products. Ideally, you would estimate the work on these project as best you could and with an acceptable level of risk.

Unfortunately, you may find that your best estimates are being ignored by management or the sales organization. The problem in that case is that if you win the business, you are probably on the hook to deliver the same level of functionality and quality, but with a significantly impaired budget.

This type of scenario puts the project team in a difficult situation. In this case, you are asked to estimate a piece of work. You deliver the estimate as requested, but then management or the sales people ignore the estimate and make up their own, which you then have to use. This is frustrating because it makes it hard to know the rules and the expectations.

If the pre-defined processes were always followed, life would be so much easier. But the hard part of project management is usually dealing with people issues. It is important to consider the other side as well. The salespeople must feel that they need to reduce the estimates to have a chance at the business. This could be to cover weaknesses in their sales processes, or this may be a fact of life if you are to get any projects at all. Of course, if you have no sales, you have no job.

The following are areas that could help improve the estimating process.

Open a Dialog Regarding Estimating Expectations

Talk to your managers and the sales organization about your team’s frustration, and explain your perspective. Note that they asked you for an estimate, you provided a realistic estimate, and they cut your estimate. This puts you in a position where you cannot deliver what the customer wants for the budget on which they agreed. Ask them for their suggestions in helping to constructively address the situation. You may find, for example, that they do not trust your numbers, in which case you can work with them on the level of detail required to gain their confidence. See if they can help you solve this problem so that both groups are more comfortable in the future.

Negotiate on Functionality

Normally, you could try to reduce some functionality to deliver within a lower budget. This may not be an option when you are dealing with a customer on a fixed bid. However, talk to sales and your managers about any areas of scope that can be reduced or removed from the proposal before it is presented to the customer. If this is a possibility, then there may be a way to commit to less while also being able to deliver the reduced scope at the price needed to win the business.

Look for Process Improvements

There may be things you can do to reduce the cost of development. Can you hire less expensive resources? Can you use new techniques that will allow faster delivery? Are there some testing techniques that would result in less rework? Can errors be caught earlier in the life cycle? You may be able to find ways to deliver the project for less effort and cost through process improvement.

Strive in the Challenge

Get yourself and your team fired up for the challenge of delivering within the reduced budget. You can still prepare a reasonable estimate, but then try to raise the level of team productivity to deliver for less effort and cost. This may be something that can be a challenge in the short to medium term, but it will not work for every project over the long term.

Play the Scope Change Game Well

In some instances, a vendor bids low on the initial contract and then tries to recover costs through scope change management. In other words, they try to force as many features as possible through scope change management, and in each case get more budget money. If the contract and requirements are written loosely, you may find that you can generate significant additional revenue through scope change management, while in fact delivering nothing more than what the customer initially had in mind. On many fixed price contracts, the revenue associated with change requests exceeds the price of the original estimate. Some project managers could bid a project at zero dollars, and then make the entire project look like scope change requests.

Pad the Estimate (But be Careful)

One option I mention but do not endorse is to pad the estimate. For instance, you could increase your estimates by 10% so that if your budget is cut 10% you can still deliver. The major disadvantage here is that the additional dollars in the estimate might make the difference between winning and losing the business. It also introduces deception into the process, and that is not good.


If this is the nature of the environment you work in, and if you don’t like the business model you work under, you may have to break the stalemate and go somewhere else where you can be more successful.


Starting a project with less money than you think you need is certainly uncomfortable. On many projects, it would be a recipe for failure. If you are in that situation often, and if it is done on purpose, morale might be bad and it can be difficult to excel. In most situations you have three options – fight for change, adapt, or flee. The options above cover all three of these alternatives.

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 or contact us at
Published in Blogs

News and Promotions

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

Twitter Update

Parse error: syntax error, unexpected end of file in /home/spektmedia/public_html/wp-content/plugins/ccode.php on line 82

Who's Online

We have 191 guests and no members online

Got something to say?