The Template Collective Blog

Project management templates… and more

Author Archives: tommochal

Four Responsibilities of Executives on Projects

January 25, 2016 – 7:48 pm

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!

Permalink | Comment (0)

Create Schedule Management Plan

January 11, 2016 – 1:58 am

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.

Permalink | Comment (0)

Five Options for Project Start Dates

December 28, 2015 – 1:55 am

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.

Permalink | Comment (0)

Seven Components to a Risk Management Plan

December 7, 2015 – 4:26 am

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.

Permalink | Comment (0)

Five Project Management Mistakes, Pt 3

November 23, 2015 – 3:24 pm

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. 

Permalink | Comment (0)

Five Project Management Mistakes Pt2

November 9, 2015 – 3:16 pm

Mistake #2: Poor scope management practices

Managing scope is one of the most critical aspects of managing a project. However, if you have not done a good job of defining scope, managing scope will be almost impossible. The purpose of defining scope is to clearly describe and gain agreement on the logical boundaries and deliverables of your project. The business requirements are gathered to provide more detail on the characteristics of the deliverables.

Defining scope means that you have defined the project boundaries and deliverables, and the product requirements. These should all be approved by your sponsor.

The project manager and project team must realize that there is nothing wrong with changing scope – as long as the change is managed. If you cannot accommodate change, the final solution may be less valuable than it should be, or it may, in fact, be unusable.

Every project should have a process in place to manage change effectively. The process should include identifying the change, determining the business value of the change, determining the impact on the project and then taking the resulting information to the project sponsor for their evaluation. The sponsor can determine if the change should be included. If it is included, then the sponsor should also understand the impact on the project, and allocate the additional budget and time needed to include the change.

The most common problems with scope change management are:

  • Not having the baseline scope approved, which makes it difficult to apply scope change management.
  • Not managing small scope changes leaving yourself open to “scope creep”.
  • Not documenting all changes – even small ones.
  • Having the project manager make scope change decisions instead of the sponsor (or designee).

If you find that your project is starting to trend over its budget and schedule, try to find the cause. In many cases you will find that you are simply taking on more work than you originally agreed to. If you do not have a good scope change process in place, it is never too late to start.

Permalink | Comment (0)

Be Proactive Managing a Project with Unrealistic Budget

October 26, 2015 – 3:16 pm

If you are a project manager dealing with what you perceive to be an unrealistic budget, the first thing you will want to do is discuss this with your sponsor to see if there are any factors that are driving the project budget. For instance, there may be budgetary restrictions. If you are a vendor, it is possible your sales people committed to a fixed price for the project. In some cases your manager or sponsor might set an arbitrary budget without much justification. It does not necessarily make your challenge any easier, but you may find that by better understanding the reason for the fixed budget, you may have an easier time getting yourself and your team members motivated to achieve it. When you have a full project management methodology you will have tools and techniques to respond to these concerns.  There are a number of responses to a project with unrealistic budgets.

  • Reduce scope. Talk to your sponsor about reducing the project scope. See if there are features and functionality that he can live without for now so that you can deliver the project within the budget specified.
  • Identify and manage the budget as a project risk. Utilizing risk management will help better manage expectations early in the project and also be a way to gather input and ideas for ways that you might be able to hit the budget.
  • Manage scope with zero tolerance. On many projects, you start with an aggressive budget and the situation gets worse because the project manager does not effectively manage scope. If you are on a project with an unrealistic budget to begin with, it is absolutely critical that you manage scope effectively and do not increase scope without an approved scope change request. Disciplined scope management will ensure that you only have to deliver what was originally promised, and that any approved changes are accompanied by a corresponding increase in budget and timeline.
  • Look for process improvement opportunities. Lastly, take an honest look at your budget and your approach for executing the project. Talk to your team, clients, and manager about any ideas they may have for executing the project at a cheaper cost. This will get everyone thinking about being part of a solution. For instance, perhaps you could buy used equipment that will still meet your needs instead of new equipment. Perhaps you can change the process for gathering requirements so that they are competed earlier. This may result in budget savings as well.

Although it appears that you are being held accountable for budgets that are not within your control, you do have control over the processes you use to manage the project. Look at all aspects of project management to see if the unrealistic budget can be achieved.

Permalink | Comment (0)

Root Cause Analysis

September 29, 2015 – 8:51 pm

A plant manager walks past the assembly line and notices a puddle of water on the floor. Knowing that the water is a safety hazard, he asks the supervisor to have someone get a mop and clean up the puddle. The plant manager is proud of himself for “fixing” a potential safety problem.

The supervisor, however, is suspicious. He is not sure why the puddle is there. It wasn’t there yesterday. He wonders what caused the puddle to be there today. Therefore, he looks for a root cause by asking ‘why?’ He discovers that the water puddle is caused by a leak in an overhead pipe. He asks ‘why’ again, and discovers that the pipe is leaking because the water pressure is set too high. He asks ‘why?’ again and discovers that the water pressure valve is faulty. He asks ‘why?’ again, and does not get a further answer. The faulty valve is the root cause of the problem. So, the valve is replaced, which solves the symptom of water on the factory floor.

Root cause analysis is a way to identify the ultimate cause of a problem. In the example above, there were many opportunities for solving the wrong problem.

  • The plant manager could have ordered more mops to be available on the factory floor.
  • The supervisor could have ordered that the overhead pipe be replaced.

However, these solutions would ultimately be wasteful and would not have solved the problem since they only addressed symptoms – not the problem itself.

Root cause analysis is usually accomplished by asking a series of ‘why’ questions. Just as the example above illustrates, you ask yourself ‘why’ a problem exists. Then you come up with one or more causes. For each of these causes, ask ‘why’ again. If you can answer that question again, then the first answer is probably a symptom brought on by the more fundamental cause. Continue to ask ‘why’ for each answer until you can no longer generate a logical response. This last answer is likely to be a root cause and is what generates the observed symptoms. You may discover more than one root cause through this analysis.

When you have identified the root cause(s), put an action plan in place to solve the problem. The symptoms should go away as well.

Not every problem has a root cause and root cause analysis is not the right problem-solving technique for all problems. But if you think that there is one underlying cause to your problem, root cause analysis may be the technique for you.

Permalink | Comment (0)

Five Project Management Mistakes

September 14, 2015 – 8:46 pm

#1: Inadequate Planning

I have heard project managers say that the time they spend planning could be better spent actually “doing the work”. This is not right. Before the project work begins, the project manager must make sure that the work is properly understood and agreed to by the project sponsor and key stakeholders. The larger the project, the more important it is that this information be defined formally and explicitly. When you think about it, many project problems can be traced to problems in planning. These include

  • Poor estimates based on not understanding the totality of the work.
  • Lack of scope change management because scope was not properly defined to begin with.
  • Issues occurring because of poor risk management.
  • Missing work because the schedule is not thought out.
  • Not understanding all the stakeholders involved.

It should not be surprising, then, that the best way to avoid this problem is to do a good job of planning the project up-front. There are four main components to the planning process.

  • Defining the work. You need to understand the nature of the project including objectives, scope, assumptions, risks, budget, timeline, organization and overall approach.
  • Understanding the schedule. You should create a  project schedule before the project starts. This is needed to help you determine how to complete the work, and to estimate the total project effort and duration.
  • Estimating costs. You and the sponsor need a good estimate of costs before the project gets going.  
  • Agree on project management processes.This will include how the project manager will manage scope, issues, risks, communication, schedule, etc.

People ask me how much time it takes to complete the project planning. The answer is “sufficient”. You need to spend the time to define the work, create a schedule, estimate the costs and set up the project management processes. If your project is small, this should not take much time. If your project is large the planning may take a long time. In other words, planning is scalable based on the size of the project.

Spending time on good planning ends up taking much less time and effort than having to correct the problems while the project is underway. We all know this to be the case. We just need to practice this on our projects.

Permalink | Comment (0)

Branding Your Project

August 31, 2015 – 4:33 pm

Branding is a more sophisticated form of marketing communication. The purpose of branding a project is to associate an emotion or a feeling with your project. This is exactly what marketing people try to do when they brand a product. For instance, The Coca-Cola Company hopes that you feel good about its products and that you will choose its products from a crowded store shelf because you like the image and emotion associated with it. Maybe it works.

The purpose of branding a project is to associate a positive image and emotion with your work. This is not something most projects need to be concerned about. However, ask yourself some questions regarding the impact your project will have on the organization.

  • Does it impact a large number of people or maybe the entire company?
  • Will it require a culture change or a change in the way people do their job?
  • Will your project make people nervous or afraid? For instance, will it result in efficiencies so that less people are required to do the same function?

These are the types of projects that would be candidates for branding.

All large projects get branded. If you don’t do anything, this branding is generally negative. It is just the nature of people that they seem to think that change is bad. Positive branding communication helps you proactively build the image you want to portray rather than getting stuck with one.

When considering a branding strategy, ask whether it is important for people to have a positive feeling about your project. For example, when people hear of your project, do you want them to think of the benefits your project is bringing or do you want them to think about how bad the project is? Should they think of the company responding to competitive challenges or should they be wondering if the project will cost them their job? Do you want them to have positive thoughts or negative ones?

There are activities that a project can perform to help with the branding campaign.  Examples of activities include establishing a positive project name, distributing banded materials, publicizing project successes, etc.

Why the fuss?

You might be wondering why this all matters. Does this sound like just a bunch of fluff and unnecessary work? It is not. It matters because it is much more difficult for your project to be successful if the people that have to change are negative. It is much easier for you if they are positive about the change – or at least neutral. That is where the value-add comes in.

Permalink | Comment (0)

« Previous Page — Next Page »

« Previous Page — Next Page »