Uncategorized

Manage Quality and Metrics – Techniques

Manage Quality and Metrics – Techniques

Gather Subjective Metrics with Client Satisfaction Surveys

Gathering metrics is important because it allows you to see how you are performing against the expectations of your clients. If the world were perfect, all of the metrics you collect would be factual, relevant and accurate. However, in many cases it is impractical or cost-prohibitive to try to gather exact and quantitative numbers.

 

One way to supplement quantifiable metrics is with client satisfaction surveys. For instance, instead of trying to measure the exact response time of an application against some service-level standard, you could simply ask your main users how satisfied they were with the application response time. It should make sense that if you are rated a 4.5 out of 5.0 (5 being the highest), you are probably doing a pretty good job in this area. However, if your survey results come back as a 1.8 out of 5.0 (5 being the highest) then it should be obvious that you are missing the mark. You did not need a complicated system, metric to tell you that. A simple customer satisfaction survey questions gets quickly to the same result.

 

In the same way, let’s say you want to gather metrics that indicate the time it takes to resolve client problems. This could involve tracking when the initial request comes in, when you first responded to the client and when the request was resolved. On the other hand, you could simply send out surveys that ask your clients if they were satisfied with the time it took to resolve the problem.

 

Surveys are by their nature qualitative; that is, they reflect the opinion of the person being surveyed. Therefore, you would not necessarily want to base your entire project success criteria on survey metrics. Some results are more easily obtained quantitatively. For instance, there is usually no reason to send out a survey to the finance department to ask them if your spending is within budget. You should have the facts available to you. However, for many other types of metrics, a qualitative survey question can be used as a substitute for the quantitative metric.

 

Collecting Project Metrics and Demographics Can Assist on Future Projects

Gathering and reporting a consistent set of metrics at the end of a project can help your organization see the trends for delivering projects over a period of time. The metrics should show how well project teams are meeting their commitments in terms of quality, cost and duration. As more and more projects report the metrics, a baseline will be established that will allow your organization to see how it is improving, or slipping, over time.

 

If you collect metrics on an organization-wide basis, you should collect some project demographics in addition to the actual metrics. Project demographics are just predefined project characteristics that provide a description on each particular project. If you store the demographics and metrics in a file or database, they can be analyzed to show the overall trends in a more discreet and granular way.

 

If you do not collect demographics, you can still compare actual cost to deliver versus the estimated cost. The advantage of gathering some project demographics is that you can compare similar projects. For instance, you can compare the cost and effort associated with delivering mainframe development projects versus web development projects. Or you could compare how well projects from the Sales organization meet their deadlines and budgets versus projects from the Finance area.

 

The other benefit of gathering project demographics is that you can use the information as input into future project estimates. For instance, let’s say you have marketing campaigns for different products. Let’s also say that you have been collecting project estimations and the actual results for cost and duration. If you had this information, you could estimate the cost and duration of a current product marketing campaign by comparing your project with similar projects that were completed in the past. This may be of help for estimating your project. The demographics you capture from completed projects can be used to search on later for new projects. (A sample worksheet to capture project demographics and metrics is available in the Template Library.)

 

Make Sure Your Metrics Tell a Complete Story

In many instances the project team publishes the results of a metric in a way that does not allow the reader to fully understand whether the results are good or bad. This is because the reader sees a metric, but they do not understand the target and they do not always understand what the metric is trying to achieve. The project manager and project team may know what a given metric is telling them, but other readers of the information may not. One way to help is to always report the metric along with the target. For instance, if you report your current expenditures to date, also include your expected expenditures at this point in the project. If you report that your project has spent $100,000 so far and your total budget is $150,000, the reader still does not have the context to know whether this is a good or bad situation. Sure you are under budget, but the work is not complete either. The better way to report this information is to state that you have spent $100,000 to date and that according to your estimate you should have spent $110,000 at this point in the project. If the trend continued, you estimate the final cost of the project to be $135,000 versus your budget of $150,000. If you report the metrics with this context, your readers can understand what the numbers are saying.

Change Management

Provide Leadership to Implement Critical Change Requests

Provide Leadership to Implement Critical Change Requests

Scope change is not inherently bad or good. However, the team can react to changes in positive and negative ways, depending on the state of the project. A typical reaction from most project teams is to just go ahead and make the approved changes. However, there is another reaction that can be more problematic – the team may not want to make any more changes. This is the scenario for this column. This situation could occur for a variety of reasons.

  • This may be a long project, perhaps requiring overtime, and people just want the project to end.
  • The proposed changes will require a lot of work, and the deadline date is being held firm. Again, overtime may be required from the team.
  • Members of the project team and the client have not had a smooth relationship on the project. There may be project team members that do not want to help the client further.
  • The changes require major upstream rework – including changes to requirements, design, and other phases that have already been completed.

All of these situations (and more) result in a scenario where the project team is not motivated to support scope changes. This puts the project manager in a tough position where he has to get the rest of the team on board for one last charge.

Frankly, it’s a tough sell. The team is usually tired and they are not motivated. In fact, morale may be poor. However, this is the time for the project manager to show leadership. Since the cause of the team problems is probably complex, the solution should be multi-faceted as well. Here are some things for the project manager to consider.

  • Explain the facts first. Do not start with a rah-rah speech right away. First meet with the team and explain the background and circumstances. Then talk through the changes that are needed and why they are important from a business perspective.
  • Acknowledge the pain. The project manager must acknowledge the problems. Let the team members know that you understand that they may not want to make the changes. Don’t dwell on it – but acknowledge it.
  • Be motivational. Now is the time to motivate the team. Appeal to their sense of working together as a team to get through this adversity. Let them know the value they are providing to the company.
  • Talk to everyone one-on-one. In addition to the team meeting, talk to the entire team one-on-one to understand where they are at mentally. Listen to their concerns and get their personal commitment to work hard and keep going.
  • Get management and the sponsor involved. Now is also a good time to ask your manager and your sponsor to talk to the team, thank them for their work so far and ask for their continued help getting through the changes.
  • Look for perks. Little perks can help a team get through motivational and morale trouble. These can be as simple as donuts in the morning and pizza for those that have to work late overtime.
  • Make sure the clients are in there with you. Normally if the project team is working extra, the clients are sharing the pain as well. However, the project manager should make sure they are.
  • Communicate proactively. Keep everyone informed as to the state of the project and the time and effort remaining. If the project manager starts getting closed and secretive with information, it causes many more problems to morale.
  • Celebrate successes. The project manager does not need to wait until the project is over to declare success. Look for milestones, or mini-milestones, as opportunities to celebrate a victory and give praise to team members.

A project manager needs to have more management and leadership skills than simply telling people to “do their jobs.” This is a tough situation and requires good people management skills to get through successfully. Success is never guaranteed, but utilizing some of these tips can help you get through a tough situation. 

Uncategorized

Understand Your IT Project Staff and Manage Them Accordingly

Remember is that it is impossible to categorize everyone within a profession.  You can make some general assumptions about technical people, but this does not mean that the assumptions apply to everyone.  As a manager, you must ultimately have multiple techniques that you can apply to different people in different circumstances.  One technique will not work for all people at all times. 

That being said, let’s make some generalizations about managing technical staff on your project.

  • They tend to be introverts.  Generally speaking, the definition of an introvert is one who is primarily more comfortable with an inward focus in life while an extrovert is generally more comfortable with an outward focus.  For example, when introverts receive a lot of new information, they tend to want to think for a while before speaking or drawing conclusions.  Extroverts, on the other hand, are more comfortable expressing ideas to others.  If they jump to the wrong conclusions, they just change their minds.  Basically extroverts are comfortable thinking out loud.  Introverts would rather think through the “rough drafts” in their minds and then talk when they think they have a coherent and logical position. 
  • They tend to think more logically than emotionally.  This tendency should be obvious.  Technical staffers typically are not motivated by a lot of “rah-rah” speeches.  In fact, they tend to be cynical of this type of motivation.  They will usually listen politely (perhaps even snickering to themselves), but the effects are short-term.  On the other hand, they can be persuaded and motivated by a logical argument.  If the logical argument can be combined with some motivational techniques, you might have a chance to actually get them excited. 
  • They tend to be problem solvers.  This is a great strength of technical staff as well as one of their weaknesses.  Most technical people love nothing better than to be confronted with a problem.  They get excited and they immediately start to apply their problem-solving skills.  The weakness comes in because there is a tendency to jump on a problem without fully understanding it first.  This often can lead to being less than optimal in the use of resources. This is also a reason why technical people don’t like to spend as much time on project planning. They have a disposition to jump in and execute the project instead of spending time to understand the nature of the project first.
  • They tend to be technically creative.  This may seem like a contradiction.  Your first thought might be that the sales and marketing staffs are the creative people.  In fact they are – in the sales and marketing areas.  They will also be the first to tell you so – because they are extroverts.  However, the technical discipline requires a fair degree of creativity as well.  This is especially true in the IT world.  In many cases, there is not one best solution to a business problem.  In the development field, for instance, analysts need creativity when they are defining a solution with the business clients.  Designers need to be creative applying technology in the best manner.  Programmers need to be creative as well in trying to apply the best techniques to build the most elegant solution.

Understanding these general characteristics is the place to start if you are a manager of technical staff.  Once you begin to understand how people work and how they are motivated, you can start to think of the best way to manage them.  Now that you have gone through many ideas, here is a summary of some of the general points you should consider as you manage your staff.

  • Try to establish an environment where people feel they have what they need to do their jobs.  This includes having appropriate hardware, software, policies, procedures, etc. 
  • Technical people like to understand the work processes in the group, and then they like to be creative in working within that structure.  So, set the high-level rules, but don’t micromanage the details. 
  • Give people as much information as they need to do their jobs.  Technical staff tends to reflect on this information.  Ask for their ideas and opinions, but give them time and ample opportunities.  Don’t expect them to react immediately.
  • Shield the team from office politics and all of the distractions that can abound in a large company.  Tell people what they need to know (see prior point), but don’t get them bogged down in the organization muck. 
  • Give people continuous opportunities to learn.  This includes encouraging people to invest the time to learn, but also helping with some opportunities.  There are many creative ways to learn new things.  Once a person has mastered a certain skill or aspect of his job and he starts to become bored, look for ways he can cross-train and learn new areas of the group. 
  • Be there when needed and respond to problems and concerns.  Not all problems can be fixed, but many times the simple act of listening and trying is enough.  People will give you credit for trying, even if the ultimate resolution to a problem is not available. 

You might note that many of these management techniques are not unique to technical staff in general or IT staff in particular.  It is true that many of the techniques can be used in other areas as well.  However, they are particularly applicable to the IT staff.

Uncategorized

Manage Quality

Many people find quality management to be one of the more difficult project management processes to implement. This is because quality is hard to define, and formal quality management requires you to collect metrics to validate the state of quality. The following process will help create a framework for the quality management process.

 

1. Create a Quality Management Plan

Develop a Quality Management Plan to identify the major deliverables, completeness and correctness criteria, quality control activities and quality assurance activities. The Quality Management Plan also describes how you will ensure that the client’s quality requirements are achieved. It is the place to describe the processes and activities that will be put into place to ensure that quality deliverables are produced.

 

2. Determine the customer requirements for quality

Work with your customer to determine their requirements for quality. The high-level characteristics of quality can be uncovered during the project definition process. The detailed quality requirements should be uncovered when you gather business requirements.

 

3. Define a set of metrics to validate quality requirements are met

Identify a set of metrics that will provide insight into the quality of the deliverables. The project manager should already be capturing overall financial and duration metrics. The quality-related metrics need to be more sophisticated. There are two areas where you are trying to manage quality – in your project work processes and in the actual deliverables you are building. You should try to capture metrics that will measure each.

 

4. Execute quality control activities

Quality control refers to activities that validate the quality of your deliverables. It is also referred to as “inspection”. Ensure that the quality control activities for every deliverable are performed while the project is underway.

 

5. Execute quality assurance activities

Quality assurance refers to the processes used to build deliverables. It is also referred to as “prevention”. Having good processes should results in good quality deliverables.

 

6. Monitor and resolve deliverable quality

You need to validate the quality of your deliverables on an ongoing basis. When quality problems are found, implement a process to determine the cause and to make improvements in the process.

Using this process will help you understand, plan for and manage the state of quality on your project.

Uncategorized

Learn About Earned Value Management (EVM) (Part 1 of 2)

Have you ever been asked how far along you were on a project? Of course you have. If you do not have a valid schedule, or if you are not keeping the schedule up-to-date, you know that your answer is pretty much a guess. If you have a good schedule and you are keeping it up-to-date, you should have a sense for how much work is remaining and what the projected end-date is. But are you 50% complete? Or 90% complete? It is not always easy to know.

Earned value metrics were established to remove the guess work from determining where you are at in relation to a baseline. Using it allows a project manager to know precisely how far along he is, how much work is remaining, what the expected cost will be, and all sorts of other interesting information.

Are you using earned value on your project today? Probably not. You are not using earned value because your organization has not adopted it. Implementing earned value on your project requires a tremendous level of discipline and a common set of processes. It is hard to apply earned value one project at a time, since no one else would understand what you are doing and why. It required an organization focus.

History

Earned value has not been around for hundreds of years. You can actually trace its beginning to the late 1800s and early 1900s, as managers attempted to make the factory floor and the production line as efficient as possible. The drive for efficiency requires a foundation in metrics and earned value was a way to measure things more precisely.

In the 1960s, the US Department of Defense began to mandate the use of earned value on defense related projects. As you might expect, if the government is contracting out projects worth hundreds of millions or billions of dollars, they want project progress updates to consist of more than “we seem to be on target.” Earned value calculations can provide a better sense for exactly where the project is against the baseline and provide an early warning if the trends indicate that the project would be overbudget or over its deadline.

EVM is based on just three core values.

  • Actual cost (AC). The actual cost of work completed as of a point in time.
  • Planned Value (PV). The budgeted cost of work you planned to complete as of the same point in time.
  • Earned Value (EV). The budgeted cost of the work actually completed as of the same point in time.

Earned Value is calculated by adding up the budgeted cost of every activity that has been completed. (Remember, this is not the actual cost of the work activities. This is thebudgeted cost.) Look at the following example:

 Today’s Date is March 31

Completed Activity A B C D Remaining Work
Target Date March 10 March 15 March 31 April 5 July 31
Budgeted Cost 20 10 15 5 500
Actual Cost 20 5 20 10 ?

Let’s say that as of March 31 you have actually completed activity A, B, C and D. Let’s calculate AC, PV and EV.

  • AC is the actual cost of the work completed. This is 55 (20 + 5 + 20 + 10).
  • PV is the budgeted cost of the work planned to be completed. This is 45 (20 + 10 + 15). Note that Activity D is not counted since it was not planned to be completed as of March 31.
  • EV is the budgeted cost of the work completed. This is 50 (20 + 10 + 15 + 5).

These three numbers seem to be interesting, but by themselves they do not tell you too much. So, we need to combine and compare the values to determine our status against schedule and budget. Sorry, but this next bit of information must wait until next week’s email.

Uncategorized

Ten Steps to Manage Issues on Large Projects

Issues are more than just common problems. They are problems that meet specific criteria. An issue is a formally-defined problem that willimpede the progress of the project and cannot be totally resolved by the project manager and project team without outside help. The processes used to manage issues can be simpler or more rigorous depending on the size of the project. Use the following process to manage issues on large projects.

    1. Identify the problem and document on the Issues FormSolicit potential issues from any project stakeholders, including the project team, clients, sponsors, etc. The issue can be surfaced through verbal or written means, but it must be formally documented using an Issues Form.
    2. Determine if the problem is really an issueThe project manager determines whether the problem can be resolved or whether it should be classified as an issue.
    3. Enter the issue into the Issues LogIf it is an issue, the project manager enters the issue into the Issues Log.
    4. Determine who needs to be involved in resolving the issueThe project manager determines who needs to be involved in resolving the issue. The sponsor may be involved, or the sponsor may not have the expertise to assist in the resolution process. For instance, the problem may be contractual and require resolution from the Purchasing Department. However, at some point the alternatives will be discussed and a resolution will be made. It is important to understand up-front who needs to be involved in making this final issue resolution.
    5. Assign to team member for analysis and alternativesThe project manager assigns the issue to a project team member for investigation (the project manager could assign it to himself or herself). The team member will investigate options that are available to resolve the issue. For each option, the team member should also estimate the impact to the project in terms of budget, schedule and scope.
    6. Gain agreement on resolutionThe various alternatives and impact on schedule and budget are documented on the Issues Form. The project manager should take the issue, alternatives and project impact to the appropriate stakeholders (from step 6 above) for discussion and resolution. The project manager may want to make a recommendation from among the alternatives as well.
    7. Close the Issues LogThe project manager documents the resolution or course of action on the Issues Log.
    8. Close the Issues FormThe project manager documents the issue resolution on the Issues Form and then closes and files this document.
    9. Add action plan to the scheduleOnce a resolution is agreed upon, the appropriate corrective activities are added to the schedule to ensure the issue is resolved.
    10. Communicate through the Status ReportThe project manager communicates issue status and resolutions to project team members and other appropriate stakeholders through the methods established in the Communication Management Plan, including the project Status Report.

Smaller projects do not need all of these steps. For instance, the issue can be documented directly in the Issues Log without the need for the separate Issues Form.

Uncategorized

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.

Uncategorized

Manage the Schedule for Small Projects

All projects need a schedule. If you have a small project perhaps the schedule is a simple checklist or Excel spreadsheet. As projects get larger they need more formal scheduling templates and tools.

The processes you use to manage a schedule also vary depending on the size of the project. Large projects need a lot of schedule management rigor. Small projects can use a lighter process. The following steps can be used to mage the schedule of a small project.

Review the schedule on a weekly basis.

Identify activities that have been completed during the previous week and update the schedule to show they are finished.

Determine whether there are activities that should be completed, but are not. Work with the individual that is assigned to the work see what is going on. Determine how much additional effort and duration are needed to complete the work and update the schedule accordingly.

Evaluate the remaining work to see if the project will be completed within the original duration. You may find that even though some activities may be completing later than planned, other activities may be completing early and the overall schedule may still be okay.

If your project is trending behind schedule, think of schedule management techniques you can apply to get back on schedule. Raise a schedule risk in your status report if the original deadline appears to be in jeopardy.

Adjust the schedule so that it reflects the remaining work to be completed, and is as accurate as possible.

Since this is a process for a small project, it would be unusual to have major problems with the schedule. The consequences of problems on small projects are generally small as well.

Uncategorized

Define the Objectives of Your Project

Define the Objectives of Your Project

Objectives are concrete statements that describe the things the project is trying to achieve. They are included in your Project Charter. An objective should be written in a way that it can be evaluated at the conclusion of a project to see whether it was achieved. A well-worded objective will be Specific, Measurable, Attainable / Achievable, Realistic and Time-bound (SMART). (SMART is a technique for wording the objective. An objective does not absolutely have to be SMART to be valid.)

An example of an objective statement might be to “upgrade the customer service telephone system by December 31 to achieve average client wait times of no more than two minutes“.

  • Note that the objective is specific.
  • The objective is measurable in terms of the average client wait times the new phone system is trying to achieve.
  • You can assume that the objective is achievable and realistic.
  • The objective is time-bound, and should be completed by December 31.

Objectives should infer the deliverables of the project. In the prior example, the objective refers to the upgrade of the telephone system. If you cannot determine the deliverables that are created to achieve the objective, the objective may be written at too high a level. On the other hand, if an objective describes the characteristics of the deliverables (such as speed or ability to handle a specific number of users), it is written at too low a level. Characteristics tend to be more requirements statements – not objectives.

If the project is a part of a larger program, the objectives of all the underlying projects should be in alignment with the program objectives.

Objectives are important because they show a consensus of agreement between the project manager and the project sponsor on the main purpose of the project. For example, the specific deliverables of an IT project may or may not make sense to the project sponsor. However, the objectives should be written in a way that they are understandable by all of the project stakeholders.

Objectives are also valuable since they provide alignment to organization goals and strategies. Your organization should not authorize projects that do not tie to goals and strategies

The project objectives should be defined and agreed upon before the project starts. The deliverables of the project are created based on the objectives. A facilitated meeting between all major stakeholders is a good way to create the objectives and gain a consensus on them at the same time.

Training

Four Steps to Show the Value of Training

Four Steps to Show the Value of Training

Many businesses struggle with whether they are getting their money’s worth in sending employees to training classes. This question can be applied to project management training as well as any other type of business training. You know the cost side of training too well. But how do you tell what the business value is?

The most common way to determine value today is to ask the trainee whether he or she thinks the class was valuable. This is very touchy-feely and doesn’t give you much information to go on, but it is probably the most that most companies ask in terms of follow-up.

A Rigorous Approach

There is a process to more rigorously determine the value received for your training dollars. These ideas are not for the faint of heart. They take more preparation and they take more of that most precious commodity – time. But see if it makes sense, and whether the results of this process will give you a much better feel for the value that you are receiving from training. You can also start with some of these steps, and try for the rest later.

  1. First, the trainee and their manager meet a few weeks before the training is scheduled to make sure the trainee is ready for the class. One of the important parts of the discussion is to identify opportunities where the trainee can apply the new skills on their job. This information should be documented so that it can be compared with a post-class assessment done later.
  • When the actual class begins each of the trainees should complete an initial survey showing their specific knowledge level of the class material.
  • A week or two after the class, the trainee completes a post-class survey showing their current knowledge level in the subject. For the most part, it is exactly the same as the initial survey from activity #2 above. This is compared to the initial survey to provide a sense for how much the trainee learned – at least in their own opinion. If this survey comes out close to the original version, it may show that the training may not have been very effective. You would expect that the post-class survey would show improvement.
  1. Here is the key step. A few months after the class, the trainee and their manager meet again for a post-class assessment, which is a follow-up to activity #1 above. In this discussion, the trainee and manager discuss the value of the class, and whether the trainee has been able to apply the new skills. In fact, the training may have been superb, but if there have been no opportunities to apply the new skills, then the business value will be marginal. The trainee and manager can then discuss the business value that was gained by applying the new skills on the job.

Summary

In most training classes today, the trainee completes the class feedback for the benefit of the training company, and then tells his or her manager how good the class was. This superficial feedback is all that is available to gauge business value. However, the real test of business value is whether the class resulted in an increased skill level that can be applied to the job to make a person more productive. This cannot be determined immediately after a class. The only way to determine business value is to determine in the months after the class whether or not the training has actually been applied on the job. If you capture this information on all your classes, you will get a much better and more fact-based view of whether the classes you pay for are providing business value to your company.