Four Responsibilities of Executives on Projects

Four Responsibilities of
Executives on Projects

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

Create Schedule Management Plan

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.

Mistake #5: Poor quality leads to poor results

Mistake #5: Poor quality leads to poor results

Like the other common project management mistakes we have looked at, problems with quality show up in a number of areas. For instance:

  • Rework. Rework means that you have to fix a deliverable that you thought was complete. Rework is always caused by flaws in your quality management process.
  • Higher operations costs. If errors are caught within the project, there is a cost associated with correct and rework. However, quality problems may surface after the solution is in operations. This causes operations (and maybe support) costs to increase.  
  • Client dissatisfaction. If a solution is of poor quality, the customer will not be happy. If the customer has a choice, they may not buy from you again. 
  • Missed deadlines and budget. Projects that build poor quality products tend to miss their deadlines and exceed their budget. This can cause the entire business case to be less attractive.
  • Poor morale. No one likes to work on a project that produces poor quality solutions. Morale and motivation tend to go down on these types of projects.

Don’t fear. Quality management can help.

What Can be Done?

There are three main components to delivering quality solutions. 

  1. Quality requirements. You cannot meet the customers expectations for quality if you don’t know what the expectations are. Quality requirements are identified when traditional functional and non-functional requirements are gathered.
  2. Quality control activities (QC). Quality control activities ensure the deliverables are of high-quality. This can include walkthroughs, completeness checklists, etc.
  3. Quality assurance activities (QA). These activities ensure that the processes used to create the deliverables are of high quality. This can include third party audits and checklists to ensure that a process were completed.

Everyone on the team needs to have a quality mindset to ensure that work is completed with a minimum amount of errors – the first time.

Five Options for Project Start Dates

Five Options for Project Start Dates

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

Seven Components to a Risk Management Plan

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.

Five Project Management Mistakes

Five Project Management Mistakes

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. 

Be Proactive Managing a Project with Unrealistic Budget

Be Proactive Managing a Project with Unrealistic Budget

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.

Proactively Manage Project Resources Without Authority

Proactively Manage Project Resources Without Authority

If team members are missing their deadlines you must first try to determine the cause. For example, if it is due to a lack of skills, this should be addressed through training or replacement resources. If it is because they do not fully understand the expectations you have, then you may have some changes to make as well.

Although the team members do not report to you functionally, their work on the project should still be input into their overall performance review.  You can try to hold people accountable by making sure they understand that you will be providing performance feedback into their review. This should also be reiterated and agreed to by the functional managers

From a process management side, there are project management techniques and processes that should be utilized. First of all, if the availability and performance of the team is in doubt, you should raise this early as a project risk. As part of risk management, you need to put a proactive plan in place to make sure that this risk is addressed. When people miss their deadlines and your deadline is in jeopardy, you may need to raise an issue and perform issues management. During issues management, you again look for the cause of the problem and try to resolve it.

In addition, make sure your team members are communicating proactively with you. In many cases, it is not the fact that people miss their deadlines that gets you frustrated; it is that the team member does not tell you ahead of time. If the team member communicates proactively, you can see the problem beforehand while you still some ability to help. If he just misses the date and does not communicate, then he is not managing expectations as should be done. By the same token, the project manager needs to communicate proactively as well. Communicate well with your team and make sure they understand dates and expectations. Also communicate proactively with the functional managers and make sure they know when there are resource sharing issues or people performance issues.

Matrix management involves a complex and delicate balancing act between project managers and people managers. The project manager usually has limited people management authority in these situations. Even so, it is possible to complete your projects successfully. There are many project management processes and techniques that can help. Utilize them to raise risks and issues when needed. Also, make sure you utilize the project sponsor. The sponsor can help you generate urgency and focus, and can also have an impact on the functional managers to make sure that you have the resources you need to be successful.

Schedule Estimating Threshold

Schedule Estimating Threshold

When you create a schedule you generally don’t know enough to enter all of the detailed activities the first time though. Instead, you identify large chunks of work first, and then break the larger chunks into smaller pieces. These smaller pieces are, in turn, broken down into still smaller and more discrete activities. This technique is referred to as creating a Work Breakdown Structure (WBS).

A question people ask is how small the activities should be before they do not need to be broken down further. This is referred to as your “estimating threshold”. Work can be broken down into smaller activities than the estimating threshold, but normally no work would be left at a higher level. The threshold can be different based on the size of your project and how well the work is understood.

You can use the following criteria as a guide. For a typical large project (say 5000 effort hours or more) the activities should be no longer than two weeks. Medium and small projects (say 1000 effort hours or less) should have activities no larger than one week. Remember that this threshold is an upper limit. You can break the activities down further if you want.

Assigning work that is smaller than your threshold allows the work to be more manageable. Think about it. When you assign work to a team member you don’t know for sure how he is progressing until the due date (or the completion date if it comes first). (Yes, you can track progress if the work proceeds linearly – like painting a wall. But many of us work in the knowledge business (IT, Sales, Finance) and it is not easy to know exactly how the work is progressing.)

Let’s look at an example. If you assign a team member work that is due in four weeks, you are not going to know for sure whether the work is on time until the four-week deadline. The worker may tell you things are on track, but you don’t really know for sure until the due date. If the work is completed you will know you are on track. If the work is late you will know it then as well. However, four weeks (or longer) is too long to wait to know if the work is on track. A better approach is to break the four-week activity into four one-week activities. Then you will know after the first week if the work is on time or not.

If at all possible you want to try to have schedule work completed within two weeks. If you give someone work that takes four weeks or longer there is just too much time before you really know if things are on-track or not. It is much better for you if you can keep the schedule feedback loop to no more than two weeks.

Managing projects at your company? Download free tools and templates from Toolkit Cafe and make your job easier

Assumptions and Risks – Two Sides of a Coin

Assumptions and Risks – Two Sides of a Coin

Let’s take an example of a common statement that is included in many Project Definitions – that the resources needed for this project will be available when needed. What kind of a statement is this? Most people would say it is an assumption. After all, when a project starts, you always assume you will get the resources you need.

However, is it really an assumption? Can you imagine starting a project where the people and equipment were not available and there was a realistic possibility that they would not be ready when you need them – perhaps because another project needed to finish first? It is not too difficult to imagine that scenario. In that case, the same statement would definitely be a risk – not an assumption.

The same statement might be an assumption or a risk depending on the circumstances of your particular project. There is some degree of uncertainty to an assumption. If the event is negative and there is a low probability that it will happen, it can be stated as an assumption. If the event is positive and there is a high likelihood it will happen, it is also an assumption. One way to identify important assumptions is to perform a risk assessment and look at all the low-risk items. Most of these low risks are not worth mentioning, but some will have significant implications if events do not turn out as you think. These are the ones that you can document as assumptions.

There are two key characteristics of risks and assumptions. First, there must be some uncertainty to the event. If there is 100% chance of an event occurring, it is simply a fact. If there is a 0% chance of the event occurring, it is fiction. Neither are risks or assumptions.

Second, assumptions and risks are both outside the total control of the project team. If the event is within the control of the project team it is neither an assumption nor a risk. It should simply be managed to make it happen.

Review the following examples for more clarity on assumptions and risks.

Statement

Assumption, Risk or Other?

We will have strong support for this initiative from our executive sponsor. Can’t tell if it a risk or an assumption. Depending on the project, there could be a high degree of risk in this statement (risk) or very little (assumption).
We will complete requirements before we begin design work. This is part of the project approach. It is not a risk or assumption because it is within the control of the project team.
Our vendor will complete their installation by October 1 Can’t tell if it a risk or an assumption. Depending on the project, there could be a high degree of risk in this statement (risk) or very little (assumption).
We must go to the moon to get the supply of meteor fragments that this project requires. This is not a risk or assumption because there is no risk involved. It is a fiction (0% true).
It is 60 miles from one project team location to the other. This is not a risk or assumption because there is no risk involved. It is a fact (100% true). (If it were not true it would be a fiction (0% true), but it would still not be an assumption or risk statement.)