Project Management

Action Items

An action item is work that requires follow-up execution. By their nature, action items normally cannot be planned for in advance. They arise on an ad-hoc basis during meetings or as a by-product of working on something else. An action item is assigned because there is not enough knowledge, expertise or time to resolve the item at the time it originally surfaced.

In many cases, action items are trivial in nature, but in other cases they can require substantial work to complete. Action items need to be assigned, worked on later and completed. (If they are not going to be completed, they should not be called action items. Instead, simply note that the item will not be followed up on and then forget about it.) Examples of action items include forwarding specific information to someone, arranging a meeting and providing a quick estimate on a piece of work.

Sometimes an action item is established to investigate an area where there may be a potential problem. Because of this, action items are sometimes mixed in with issues. However, this is not right; an action item should not be confused with an issue. An issue is a problem which will have a detrimental impact on the project if left unresolved. An action item may lead to the discovery of an issue or a risk (a potential issue in the future), but the action item itself is not an issue.

There are two common approaches used to manage action items. The best approach is to document the items as activities in the project schedule. A resource and end-date are assigned as well, and the activity is then managed and tracked as any normal activity. In general, this is the better approach to follow, because it keeps the work items in one place and allows the project manager to enforce the discipline of knowing ‘if it’s not on the schedule, it will not be worked on.’ This approach also allows the project manager to see the impact of the action items on the schedule. For instance, you may have a small action item that is 3 hours of work. If you assign this action item to a person on the critical path, you will see the resulting delay to your project. This may result in you assigning the action item to someone else instead.

The second approach is to create a section on your meeting minutes for action items. Action items can be placed here if they are trivial (less than two hours) and they are scheduled to be completed by the next meeting. If you use this technique you can start each meeting with a review of the prior action items to validate that they are completed and then cross them off the list.

Understand the Difference Between Issues Vs Action Items

In many cases, project managers are not using the Issues Log to identify and track true issues. Many items that are classified as issues are really risks (potential problems) or just action items. Action items are activities that must be followed-up on at some time. They may or may not involve problems for the project. If you find that your Issues Log has dozens of items on it, you are probably tracking many action items. Because issues are large problems, there should not be many items open at any one time. If you find that your Issues Log is full of items, chances are that you are tracking much more then issues. This can result in true issues being hidden and not worked on as they should.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Wideman Glossary Term of the Week - Monte Carlo Simulation

• A method for calculating the probabilities of outcomes by simulation, running a model many times, using a computer. A Monte Carlo model is an example of a "stochastic" model.

• The technique used by project management applications to estimate the likely range of outcomes from a complex random process by simulating the process a large number of times.

• See Monte Carlo Method.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Don’t “Goldplate” (Deliver More than the Client Requested)

The term goldplating refers to delivering more than what the client requested. Even though it might seem that this is a good thing, it is wrong for two reasons. First, the primary focus of the project should be to make sure that you deliver what the client wants - on time and within budget. By adding in additional work, you increase the risk that the project will not meet its deadline or budget. If you end up missing your deadline date, you will not find sympathy if you explain that the date was missed because of adding more work than the client agreed to.

Second, if you deliver more than the client expected, there is always the implication that you could have delivered what they wanted for less time and duration. if you goldplate, you are taking it upon yourself to make a business decision on what is of most value to the client. There may be some good reasons why the additional features were not included in the initial project scope. They may, in fact, be of marginal value to the client. There may be more value in having the solution completed early and for less cost. The point is that this is a client decision and not one that the project manager should make.

Under-promising and over-delivering should only apply to delivering earlier or for less money than was anticipated. It should not include delivering more requirements than were asked for. The client may, in fact, ask you to include more requirements in the solution. If they do, the new requirements should be processed through scope change management. However, the client may have other uses for the savings that are more important to them. If you can complete the project earlier or for less money than was budgeted, let the client make the decision on what to do with the good fortune.

Make Sure Quality Management Focuses on Processes, Not People

The focus of quality management is to build the right processes so that the entire team can produce the deliverables that meet the client’s expectations. Therefore, if a particular deliverable has a quality problem, the project manager and project team should focus on how the project work processes can be improved - not on trying to determine who is to blame.

Most problems with quality are the result of poor or inadequate work processes, not because of the malicious act of a particular person. In fact, it is thought that at least 80% of quality problems can be resolved by changing and strengthening business processes. Less than 20% of problems are under a team member’s control. Furthermore, the processes that your organization utilizes are largely determined by management. So, when workers or team members have quality problems, it is important for managers to identify the weak or broken processes involved and fix them. This is a management responsibility – not the responsibility of the staff. This does not mean that everyone cannot be involved. However, the setting up and enforcement of business processes is primarily a management responsibility.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Wideman Glossary Term of the Week - Life Cycle Cost ("LCC")

• The total cost of a system or facility over its full life, including the cost of development, acquisition, operation, support and disposal.

• The total cost of implementation and ownership of a system over its useful life. It includes the cost of development, acquisition, operation, maintenance, support, and where applicable, disposal.

• The sum of all costs over the useful life of a building, system or product. It includes the cost of design, construction, acquisition, operation, maintenance, and salvage (or resale) value, if any.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Include Information of Value in the Status Reports - Not the Mundane

Let’s face it: Status Reports are typically not as effective as they should be. This is true for team members that submit Status Reports to the project manager, as well as project managers that are submitting Status Reports to their major stakeholders. One of the major reasons is that the people completing the reports look upon them as a chore and not as a way to communicate valuable information. You typically get a Status Report that is very brief and says nothing, or else you get a Status Report that contains all the mundane activities that a person did.

The person creating the Status Reports needs to write it so that the reader can use the information in them in the decision-making process. The information needs to be of value. The writer should ask himself whether the information on the Status Report is there to really communicate something valuable or is it just taking up space.

Typically the Status Report should focus on the following:

• Accomplishments against the assigned activities on the schedule

• Comments on work that should be completed but is behind schedule

• Problems (issues) encountered, the impact to the project, and what is being done to resolve them

• Scope change requests

• Newly identified risks

• Observations that will be useful to the reader

If you focus on this type of information in your Status Report, you will find that the information is meaningful and can be used to help manage the project and keep the stakeholders informed. People will stop paying attention if you report on the trivial events of the reporting period.

Use Appendices for the Details

You want to focus on meaningful information in the status report. However, you may find that some of your audience finds meaning in the exceptions while others find meaning in the details.

Does that mean you need to create two status reports? You should not need to. One of the ways to satisfy both audiences is to write the formal Status Report as an exception-based document and include the details as appendices (attachments). For instance, most readers want to know the accomplishments from the prior period and the planned accomplishments for the next period. However, your manager might want to see the entire schedule. To satisfy both, just include the schedule as an appendix. If you are emailing the information, you could email the current schedule as a separate document from the basic Status Report.

A similar example is a situation where you note an accomplishment about completing a significant amount of training. Your client might want to see the names of the people trained. Again, do not include this level of detail in the body of the report. Include the information in an appendix instead.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Wideman Glossary Term of the Week - Risk Quantification

• Process of applying values to the various aspects of a risk.

• Evaluating the probability of risk event, effect and occurrence.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Estimating Threshold

When you create a workplan 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).

An appropriate question to 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), any work that is greater than 80 hours of effort should be broken down into smaller pieces. Medium-sized projects (say 1000 effort hours) should have activities no larger than 40 hours. If the project is small (say 200 hours), you should break down the activities into work no greater than 20 hours. Remember that this threshold is an upper limit. You can break the activities down further if you want.

Assigning work that is smaller then your threshold allows the work to be more manageable. For instance, if your project is 250 hours and you have activities that are 80 hours each, you don’t have enough time to recover if one of the activities is late. However, if the largest activity is 20 hours, you are able to find out much more quickly if work is not being done on time.

Of course, it is possible that activities that are to be worked on in the distant future may not be able to be broken down less than the threshold because there may be too much that is unknown about the work itself. In this case, one approach would be to actually break the work into a couple smaller projects. The second project can be defined more accurately based on the results of the first project.

If you do not have the option of multiple projects, the future work can be left at a level higher than the threshold. However, if you leave future work at a high-level, it is still critical to break the work into smaller pieces at least two to three months before you need to start executing the work.

In addition to allowing you to manage the work more effectively, another reason to break down activities into smaller pieces is to make sure that you understand what the work means. When you assign a team member an activity from the workplan, they may not understand what the work is and they may ask you for an explanation. If you don’t know what the work means either, you will be in trouble. So, you should make sure that the work is broken down into a level small enough so that the activities are understandable. For instance, if an activity that is estimated at 80 hours has never been done before, it may still need to be broken down into smaller activities to ensure that the team member that is assigned the work knows exactly what is expected.

These two factors – the ability to manage the work effectively and to understand the work required - should drive your decision on how small to make your activities.

Duration Threshold

An additional threshold to consider is the duration threshold. In general (but not a hard and fast rule), the duration of activities should be broken down to a level that is no more than twice the project team reporting cycle. For instance, if you are receiving a formal status update from your team every week, the duration threshold should be no more than two weeks. Or, if you have a status meeting weekly, the assigned activities should be no more than two weeks. This rule ensures that there will be no more than two status periods before an activity is completed or is flagged as late. As an example, if you meet with your team weekly and the activity duration is no more than two weeks, then no activity will be active for more than two status meetings before it is completed or late. On the other hand, if you have an activity that has a duration of five weeks, it is possible that up to five status meetings will go by before you know for sure whether the activity will be completed on schedule. This is an example of where the activity needs to be broken down at least one more level. Smaller activities allow problems to be uncovered and fixed much earlier.

Note that duration threshold comes into play when the schedule is finalized and not when the WBS is created. When the WBS is created you only know the estimate of the effort hours. After the resources are applied, you can validate that the duration threshold has been met.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

eman Glossary Term of the Week - Overhead

• Costs incurred in the operation of a business which cannot be directly related to the individual products or services being produced. See also Indirect Cost.

• Costs arising from management and supervision, office expenses, interest-during-construction, and any other general costs associated with the project not directly attributable to design or construction.

• A general term often used to identify any indirect cost.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -