Understand the Risk Tolerance Level in Your Organization

/in , /by

All projects have risks and all risks have the potential for negatively impacting the project. You use risk management to determine the risks that are important enough to manage. During the risk identification process, you may encounter many risks that have some likelihood to occur and have a marginal impact to the project. The question to ask is whether the risk has enough impact on the project to worry about (this same question occurs for both qualitative and quantitative approaches). The answer says something about your risk tolerance.

For example, let’s say you identify a risk that is very likely to occur, but has an impact of $100 and one-half day duration. You may choose not to manage it. You cannot list this as an assumption since there is a good chance the risk will occur. However, the impact is small enough that you are willing to absorb the cost if it occurs, rather than deal with managing the risk (which would probably be more costly). Therefore you would choose a risk management strategy of leaving the risk.

In the prior example, the numbers were fairly trivial and the risk was easier to ignore. But, ratchet the impact up a little higher. Let’s say the risk now was $500 and one day duration. What about $100,000 and three months duration? Of course, the answers are all relative based on the size of the project. If your project had a $20,000 budget, a $1,000 risk impact might be worth managing. If your project budget is one million dollars, the risk impact of $1,000 would just be marginal.

When you are performing risk identification, you need to determine your tolerance level for risks. This will help you focus on the risks that are important and above your tolerance level, while ignoring risks where the impact falls below the tolerance level. Risk tolerance is also cultural in your organization. Some organizations are bigger risk-takers and will accept a higher level of risk on projects. They will also tend to have a higher threshold before they chose to manage a risk.

On the other hand, some organizations are more risk-averse. They will tend to accept less risky projects and they will also tend to have a lower threshold to manage risks. For example, let’s say you have a similar project in both organizations. The project managers in these risk-averse organizations will tend to manage risks that a project manager in the other organization might choose to leave.     

The Power of the Aligned Organization

/in /by

When was the last time you rode in a car with wheels that were not properly aligned? Chances are it was a pretty rough ride. The car either pulled in one direction, making it hard work to keep it in your lane, or, it worked against itself as one tire pointed one way and another tire another way.


The same thing can happen in our companies. The ride can be pretty bumpy, not to mention noisy, unless everyone is pointed in the same direction. That’s why it’s important to understand the five benefits of an aligned organization

Benefit #1 – Ensures Everyone Works on the Right Things


The first benefit of an aligned organization is that with a common goal for everyone to strive towards, the right things are worked on. Here’s the trick – you need make sure that everyone clearly understands the goal and the end game. The best way to accomplish this is to clearly communicate the strategy of the company. What are the three to five most important things your company is working on? Once those are communicated and understood, you can then align everyone’s activity to accomplish those initiatives.

Benefit #2 – More is Accomplished


An aligned organization is structured and disciplined. This doesn’t mean the company lacks creativity or is oppressive. Rather, it means that projects not aligned with company strategy are not allowed to infiltrate the company. Alignment allows resources to stay focused on the tasks at hand and not waste time on other distractions.

Benefit #3 – Teamwork Increases


A third benefit of alignment in the organization is increased camaraderie. The ‘us’ versus ‘them’ mentality is nipped in the bud while everyone works toward the same goals together. Departments and groups of people that are not properly aligned have a tendency to look after their own interests. This will still occur in the aligned organization, but there is also more of, “what can I do to help?” Team members in the aligned organization realize that everyone must cross the finish line at the same time in order for the project to be successful.

Benefit #4 – Profitability Rises

 

An aligned company is a company that runs efficiently. Engaged teams that are working on the right things are naturally going to get more done. Getting more done in less time results in increased profitability. There are fewer misunderstandings and mistakes – and rework is few and far between. Alignment helps keep resource costs in check, and reduces expenses, both of which are areas that impact the bottom line.

Benefit #5 – Opportunities Abound

 

People like working with people and companies that have a track record of success. The aligned organization will have plenty of success stories to tell. That credibility allows salespeople to sell more, executives to explore new strategies, and managers to optimize opportunities. It generates more top-line revenue that ultimately trickles down to the bottom line.


A car that is not aligned will still run; however, the ride is rough and it’s not very efficient on gas. Once aligned, the car rides much more smoothly and fuel efficiency increases dramatically. Your company can still run if it’s not aligned, just not very efficiently. Take the time to align your organization and begin realizing the benefits!

The Customer May Not Know Enough to Completely Define the Project

/in /by

Sometimes the project manager places too high an expectation on the amount of foresight and vision that customers and sponsors have. In many cases, the project manager will go to the customer looking for answers to help define the project and the customer will not have all of the information needed. This happens all the time and it does not mean that the customer does not know what they are doing. In many cases, especially for large projects, the customer has a vision of what the end results will be, but cannot yet articulate this vision into concrete objectives, deliverables and scope. 

There are three approaches for when you don’t know very much information on the nature of the project.

Increase Estimating Range Based on Uncertainty

Based on having less than complete information, the  project manager may feel the need to guess on the details. This is not a good solution. It is better to state up-front everything that you know, as well as everything that you do not know. If you are asked to come up with estimated effort, cost and duration, you will need to provide a high and low range based on the uncertainty remaining. On a normal project, for instance, you might estimate the work within +/- 10%. On a project with a lot of uncertainty, the estimating range might be +/- 50%. 

Break the Work into Smaller Projects

Another good alternative is simply to break the work down into a series of smaller projects based on what you know at the time. Even if the final results cannot be clearly defined, there should be some amount of work that is well defined, which will, in turn lead to the information needed for the final solution. You can define a project to cover as far as you can comfortably see today. Then define and plan subsequent projects to cover the remaining work as more details are known.  For instance, you could create a project that gathered business requirements, and then use the results of that project to define a second project to build the final deliverables. 

Uncover the Details as the Project Progresses

If you are not allowed to break the project into smaller pieces, you should at least know enough that you can plan the work for the first 90 days. In this third approach, you plan the short-term work in more detail, and leave the longer term effort more undefined. Each month you should redefine and plan the remaining work. As you uncover more and more information, you can plan the remaining work at a more detailed level. As you uncover more details, you can refine your estimates and work with the sponsor to make sure it is still okay to continue.

This last approach uses an Agile philosophy. Agile projects are generally exploratory. The details of the project are uncovered as the project progresses. (There are many more differences in Agile projects, but this philosophy is one.) In a traditional project management model this would also be known as ‘progressive elaboration’ – which also means more details are uncovered as the project progresses.  

Four Responsibilities of Executives on Projects

/in /by

A Primer on Processes and Templates

Recipes for cooking are a beautiful thing. A recipe tells you the ingredients and how much of each you should include in whatever you are making. It then describes what you need to do to these ingredients in order to make a dish that is not only edible, but tasty as well. It’s great that someone else has already spent the time in putting together a recipe to follow that nearly guarantees success each time.
To a certain extent we use recipes in our profession as project managers. The recipes we follow are the processes and templates that guide our projects to success each time. How can you put a process together and make the most of templates? Consider the following:
A Primer on Processes and Templates

Start with Phases

To put a process together, a good starting place is defining the major phases in which a project must go through. Think about how a project moves through your organization, and document those major steps. For example, a simplified software development approach would include the following phases: Planning, Design, Development, Testing, and Implementation. These phases are the framework in which you begin filling in details about the process.

Move on to the Outputs
The next area to concentrate on is the outputs, or end results, from each of these major phases. Ask yourself what tangible deliverable needs to be complete by the time you finish the Planning, Design, or Development phases. Focus on tangible results, or something you can see, touch, perform an action on, or feel. For example, the Planning stage is going to be filled with meetings and conversations that by themselves do nothing to move the project forward. However, the approved Business Requirements Document is an invaluable output that can propel the project forward to the next Phase of Design.

Back up to Inputs

Now that you have the tangible end results (or deliverables) of each phase defined, ask yourself what needs to be present at the beginning of each phase to create such results. Continuing with our example above, the output of the Development phase would be software functionality that can be tested. In order to accomplish this, the engineering team will need High Level and Low Level design specifications as Input. This will allow them to know not just what they are going to build, but more importantly, how they are going to build it.

Establish Conversion Activity

You now have the Inputs and the Outputs for each of the phases of your process. The final step is to determine what needs to be done to convert the Inputs to Outputs. Think about it this way…what has to be done to change the gooey mess of runny batter into a cake? You need to bake the cake. There’s your conversion activity. Likewise, what do you need to do to convert software that is ready to be tested to software that is production ready? You need to create test plans, execute test plans, and document the results.

What About Templates?

Templates are incredibly useful for all areas of process you create. You can use templates for your inputs (i.e. Business Requirements Document), your Outputs (i.e. an approved User Acceptance document from the customer) and all points in between. Create templates that will provide consistency and make it easy to transition from one phase to the next with confidence.

One word of caution when it comes to process and templates…don’t overdo it! Create just enough process and documentation around your project to float the boat. It can be tempting to have a process or template in place for every little thing. Resist that urge. Remember, too much of a good thing can ruin a good thing. Stick to the recipe and you’ll be able to guarantee consistent results time and time again!

Manage Political Problems as Issues

/in /by

The larger your project gets, the more you will find that the issues you encounter are political in nature. “Politics” is all about interacting with people and influencing them to get things done. This can be a good thing, a bad thing, or a neutral thing, depending on the tactics people use. Let’s consider some examples of how utilizing political skills might be good, but can also be bad.

  • You are able to move your ideas forward in the organization and get people to act on them (good), by currying favor, suppressing other opposing ideas and taking credit for the ideas of your staff (bad).
  • You have an ability to reach consensus on complex matters with a number of different stakeholders (good),by working behind the scenes with people in power, making deals and destroying people who don’t get on board (bad).
  • You receive funding for projects that are important to you and to your organization (good), by misrepresenting the costs and benefits, and by going around the existing funding processes (bad).


The point of the examples is to show that influencing people and getting things done in a company is a good thing and “office politics” can have good connotations or bad. 

Dealing with office politics is not a standard project management process. However, once the politics start to impact the project adversely, the situation should be identified as an issue, since it is a problem whose resolution is outside the control of the project team. You can’t utilize a checklist to resolve political issues. Political problems are people-related and situational. What works for one person in one situation may not work for another person in the same situation because people, and their reactions, are different. Identifying the problem as an issue will bring visibility to the situation and hopefully get the proper people involved in the resolution. Keep three things in mind to manage a political issue.

  • Try to recognize situations and events where politics are most likely to be involved. This could include decision points, competition for budget and resources, and setting project direction and priorities.
  • Deal with people openly and honestly. When you provide an opinion or recommendation, express the pros and cons to provide a balanced view to other parties. Make sure you distinguish the facts from your opinions so the other parties know the difference. 
  • If you feel uncomfortable with what you are asked to do, get your sponsor or your functional manager involved. They tend to have more political savvy and positional authority, and they should be able to provide advice and cover for you.

If you feel good about what you are doing, how you are influencing and how you are getting things done, then you are probably handling office politics the right way. If you feel guilty about how you are treating people and if you have second thoughts about the methods you are using to get things done, you are probably practicing the dark side of office politics.

Four Responsibilities of Executives on Projects

/in /by

An executive has administrative or supervisory authority in an organization. That authority is used in a number of ways on projects. An executive is typically responsible for the Business Case of a project, which is used to determine whether the project should even be started. Once the project is approved they can impact the success of your project in four key areas.

1. Sponsorship and Funding

Every project within a company starts with an idea. It’s hard for that idea to go much further without backing from the right person and some money to make it happen. An executive can provide the sponsorship and funding your project needs to get off the ground. They are responsible for signing off on the project charter, which describes the project, gives you the authority to manage and, most importantly, allocates the necessary funds to keep it alive.

2. Escalations and Resolution

The second role an executive plays in your projects is to be the go-to person when unresolved problems surface. An executive needs to be on the escalation path, and more importantly on the resolution path of your projects. There are going to be times when others are unresponsive to the project’s needs, or in a dispute about the best direction to take. An executive can use his position to break through these bottlenecks. Here’s a hint: shorten the escalation process as much as possible. Rather than go through a gradual escalation of layer after layer of management, take it to the highest level of management and get it resolved in a fraction of the time.

3. Monitor Projects

Executives sponsor and fund projects. They should also be interested in how the project progresses. They should be interested in ore than when the project starts and when it finishes. They should monitor the project. This includes reading and understanding status report, approving major deliverables and being involved in gate reviews. Of course, the projects that are of interest will vary based on the level of the executive. Senior managers should monitor the larger and more strategic projects. Middle managers monitor more tactical projects.

4. Coach Project Managers

Let’s face it: despite the stereotype, most executives are talented, skilled, and experienced people. Tap into their knowledge. You’re going to run into rough patches on your projects from time to time or will need to make decisions when answers are not so obvious. Sit down with a respected executive and bounce some ideas off of them. At the very least, they may validate that you are on the right path or give you the encouragement you need to keep going. More often than not, they will provide you with a fresh perspective to help make your project a success.

If you want to benefit from the value an executive brings to project management, it’s up to you as a project manager to optimize their role on your projects. View them as another resource you need to bring your project to closure. Who knows, with such a great track record of project success, you may end up sitting in the corner office yourself!

Create Schedule Management Plan

/in /by

The Schedule Management Plan describes the process used to develop and manage the project schedule. Not all projects need a Schedule Management Plan, but if your project has a complex schedule that requires special handling, you may find this plan helpful.

The components of the Schedule Management Plan can include:

  • Roles and responsibilities. You can describe different roles and their ability to access the project schedule.
    • Schedule owner. This is probably the project manager.
    • Who can update? Normally the project manager, but on larger projects it could be more complex. For instance, a Project Administrator might make the initial schedule updates based on the project status reports and then provide this draft to the project manager for final updates. It is also possible that team members will update the status of their assigned activities and the project manager will perform final analysis after those updates.
    • Who can read? Usually the schedule is not considered confidential – anyone can read it.
  • Update frequency. You should describe the timing of schedule updates. In many projects the schedule will be updated on the Monday morning. You should also comment on whether the schedule will be updated weekly or bi-weekly. It is recommended that you update the schedule weekly.
  • Progress feedback. This describes how the schedule feedback will be delivered. In many cases this will be in the team member status report. However, it is possible that the progress update will come during a team meeting or through an email.
  • Schedule change review and approval. This is where you define the process required to evaluate and approve proposed schedule changes. It defines the authority for accepting and approving changes to schedule. This approval process does not include internal activity deadlines. It applies to changes in the overall project deadline. It is possible that the project manager may have some discretion to exceed the deadline date by some number of days or weeks, but after that threshold some formal body may need to approve the change.
  • Tools. Describe about any scheduling tool that will be used on this project, who will have access to the tool and what various people can do with the tool (read the schedule, update schedule, etc.)
  • Reports. Comment here on the types and names of reports you are using to manage the project, who will receive them, the frequency of the reports, etc.
  • Schedule integration. Normally each project keeps an independent schedule, but in some instances your master schedule is the result of a roll-up of other underlying schedules. It is also possible that your schedule could be integrated and rolled up to a higher-level program or portfolio schedule.

We believe that these project management plans must provide value to the project manager. If your schedule is not so complex you probably do not need to create the Schedule Management Plan. On the other hand, the project manager should create a Plan if it provides value on projects with large and complicated schedules.

Five Options for Project Start Dates

/in /by

 

One of the characteristics of a project is that it is a temporary endeavor. In other words there is a start and end-date. This seems simple enough until you start to try to define exactly what these dates mean. Is it after the Project Charter is signed? Is it when the schedule is finalized?

There are no universally recommended definition for either date. It depends on each organization and whether there are any implications for choosing one alternative over another. Here are some of the options for identifying the project start-date.

  • The need/idea is generated. The definition you choose can depend on what the implication is. You may choose this definition of project start date if your company is trying to focus on the time it takes between when an idea is generated until the idea is fulfilled. Your company may be concerned that it takes too long to commercialize good ideas. If your company wants to minimize this total time span between idea and fulfillment, you might go with an early project start-date definition like this.
  • A budget is approved. In this definition, an idea has been generated and the idea has made it far enough that a cost/benefit statement has been prepared. The project has also made it through the prioritization process and an actual budget has been approved. Keep in mind that the budget may have been approved during the prior year business planning process. The actual work may not start until the following year. Therefore, this definition may also start the clock too early for many organizations.
  • A project manager is assigned. This one is more common. The assumption here is that the project manager is the first resource assigned to a project. When the project manager is assigned, the project initiation and planning begins. This is the definition for project start-date in the TenStep Project Management Process.
  • The Project Charter is approved by the sponsor. In some organizations the project officially starts when the sponsor approves the Project Charter. Some companies require an approved Project Charter and schedule before the project team can be allocated.
  • The project kickoff meeting is held. Using this definition, the planning work is considered to be “pre-project”. The projects starts with a formal kickoff meeting with the major stakeholders and the project team. The kickoff meeting is the time to tell everyone that the project is ready to begin.

In some respects the exact definition of the project start is not as important as whether the definition is applied consistently. For example, if you wanted to compare the time it takes for two projects to complete, it is important that both projects use the same definition for start and end date.

Seven Components to a Risk Management Plan

/in /by

The Risk Management Plan describes how you will define and manage risk on the project. This document does not actually describe the risks and the responses. This document defines the process and techniques you will use to define the risks and the responses. The information in this plan includes:

  • Roles and responsibilities. This section describes the leading and supporting roles in the risk management process. The project manager typically has overall responsibility for risk management, unless the team is large enough that this role can be delegated to another team member – perhaps a specialist. Third-party risk management teams may also be able to perform more independent, unbiased risk analyses of project than those from the sponsoring project team.
  • Budgeting. Discuss your budget for risk management for the project. Since you may not know enough to request budget for risk management you can also describe the process that you will use to determine a risk management budget estimate.
  • Timing. Defines when the initial risk assessment will be performed, as well as how often the risk management process will be conducted throughout the project life cycle. Results should be developed early enough to affect decisions.
  • Scoring and interpretation. You should define risk scoring and interpretation methods appropriate for the type of the qualitative and quantitative risk analysis being performed. Methods and scoring must be determined in advance to ensure consistency.
  • Thresholds. The threshold level is how you determine which risks are important enough to act upon.  The project manager, client, and sponsor may have a different risk threshold. The acceptable threshold forms the target against which the project team will analyze risks.
  • Communication. Describe how the information on risk will be documented and communicated. This includes the risks themselves, the risk responses and the risk status.
  • Tracking and Auditing. Document how all facets of risk activities will be recorded for the benefit of the current project, future needs, and lessons learned. Also describe if and how risk processes will be audited.

Other sections can be added to the Risk Management Plan as needed.

Five Project Management Mistakes, Pt 3

/in /by

Mistake #3: Not Keeping Schedule Up-to-Date

Many project managers create an initial schedule but then don’t do a good job of updating the schedule during the project. There are trouble signs that the schedule is not being updated.

  • The project manager cannot tell exactly what work is remaining to complete the project.
  • The project manager is unsure whether they will complete the project on-time.
  • The project manager does not know what the critical path of activities is.
  • Team members are not sure what they need to work on next (or even what they should be working on now).

It is a problem when the project manager does not really understand the progress made to date and how much work is remaining. When this happens, the project team is not utilized efficiently on the most critical activities.

There are a couple other common scheduling problems.

  • Infrequent updates. Sometimes the project manager updates the schedule at lengthy intervals. For instance, updating the schedule every two months on a six-month project. This is not often enough to keep control of the schedule. The schedule should be updated every week or two.
  • Managing by percent complete. All activities should have a due date. As you monitor the work, keep focused on whether the work will be completed by the due date. It is not very valuable to know that an activity is 70% completed. It is more valuable to know if the due date will be hit.
  • Assigning activities that are too long. If you assign a team member an activity that is due by the end of the week, you know if the work is on-track when the week is over. However, if you assign someone an activity that does not need to be completed for eight weeks, you have a long time to go before you know if the work is really on schedule. Keep the due dates within a reasonable timeframe. 

It is not easy to catch up a schedule once the project is started. Typically, by the time you realize you need to update the schedule, your project is already in trouble. Updating the schedule at that point only shows how much trouble you are in. The much better approach is to keep the project up-to-date, and ensure that it contains all of work necessary to complete the project.