Remember these Ten Costs of Poor Quality

/in , /by

Remember these Ten Costs of Poor Quality

It costs money and time to build a quality solution. You may think that it is cheaper to skip many of the quality management steps, but this is usually not the case. It is important to recognize that there is also a cost to having poor quality. These costs may not be apparent when the project is progressing, but should definitely be taken into account as part of the full life cycle cost of the solution being delivered. Examples of the cost of poor quality include:

  1. Rework. This is work that is required to fix deliverables that you thought were already complete and correct. Whenever you have rework it is a sign that your quality management process is not as rigorous as it needs to be. 
  2. Bad decisions. If there are errors in your solutions you will end up making decisions based on bad or misleading information. These bad decisions could have long term consequences for your company. 
  3. Troubleshooting. It takes time to investigate to determine the cause of errors and defects that occur on the project.
  4. Poor morale. No one likes to work for an organization or a project that has poor processes or produces poor quality solutions. Costs of poor morale include increased absenteeism, higher turnover and less productivity from the staff.
  5. Warranty work. This includes work that is performed on a product or application for free (or a reduced price) under a warranty. If your project produces a product with lower quality you will see a rise in the cost of warranty claims.
  6. Repairs / maintenance. This is work that is done to fix problems after the solution goes live. Poor quality solutions usually have much higher repair and maintenance costs.
  7. Client dissatisfaction. If a solution is of poor quality, the client will not be happy and may not buy from you again at a later date. If the project is internal, the client may not want to use the project manager and team members on subsequent projects. 
  8. Help desk. Much of the effort and cost of maintaining a help desk service is required because the users have problems with project solutions or have questions understanding how to utilize the solutions.
  9. Support staff.  Much of the effort and cost associated with a support staff is needed to maintain a solution because of problems, errors, questions, etc.
  10. Mistrust. When project teams deliver poor quality products the client starts to develop a level of mistrust with the project team and the performing organization. The client starts to believe that the project organization can never build a good product and this starts to lead to a mistrust of project team skills, processes and motivation.

Quality management has a cost. There is also a cost to delivering poor quality. One of the key points of formal quality management is that if you spend quality time on internal quality management (prevention and inspection), you will save substantially on the internal and external failure costs. In fact, the savings for external failure costs can be substantial. If you spend more time focusing on building a better quality product during the project, the cost of operating the product long-term may be dramatically reduced.

Use Pareto Analysis to Solve the Most Important  Problems First

/in /by

Use Pareto Analysis to Solve the Most Important
Problems First

Pareto analysis can be used when you encounter multiple related problems or a common problem with multiple causes. This technique can be used if there are enough occurrences that you can categorize and count them. In other words, this technique does not work if there is just one root cause.

The purpose of Pareto Analysis is to observe the problems and determine their frequency of occurrence. This, in turn, gives you the information you need to prioritize your effort to ensure you are spending your time where it will have the most positive impact.

Pareto Analysis is based on the classic 80/20 rule. That is, in many cases 20% of the problems cause 80% of the occurrences. For example, let’s say you have a problem with a product failure, based on a number of causes. Through observation and collecting metrics, you determine there are eight causes. Rather than attacking the causes randomly, a Pareto Analysis might show that 80% of the problems are caused by the top three causes. This gives you information to know which causes to solve first.

The tool associated with this problem solving technique is the Pareto Diagram. It is a chart, graph or histogram showing each problem and the frequency of occurrence. It is created as follows:

  Developing a Pareto Diagram
1 Create a table listing all observed problems or causes.

For each problem, identify the number of occurrences over a fixed period of time.

Problem Count
Problem 1 115
Problem 2 25
Problem 3 5
Problem 4 50
Problem 5 5
Problem 6 15

 
2 Arrange the problems from highest to lowest, based on the number of occurrences.
3 Create a new column for the cumulative total.

Problem Count Cumul % Total
Problem 1 115 53%
Problem 4 50 77%
Problem 2 25 88%
Problem 6 15 95%
Problem 3 5 98%
Problem 5 5 100%

You could add other columns such as the severity of the problems and the cost and effort to resolve the problem.

Notice that this gives you important information. Even though there are six total problems identified, you need to resolve problems #1 and #4 first (all things being equal). That is where you will achieve the most impact. If you decided to work on problems #3 and #5 instead, the result of your effort would be almost meaningless. This does not mean that you do not want to resolve the other problems. However, this Pareto Analysis gives you information to know the order in which the problems should be resolved. It also provides a sense as to the relative value you receive for resolving each problem. Of course, you may determine that problem #6 can be resolved quickly and you may choose to solve that one early. The Pareto Diagram does not tell you what to do. It provides information to you so that you can make the best decisions. 

Agile 101 – Refactoring

/in /by

Agile 101 – Refactoring

In a traditional IT development project there is a tendency for one person to write entire programs to implement certain functionality. A developer tends to own the code that she writes. 

This is not the case with an Agile project.   Agile projects build incremental solutions over time. It is very possible, and perhaps likely, that a component that was written to support a specific piece of functionality may need to be updated later with the introduction of some other use case with related functionality.

On an Agile project when the second developer works on a module that another developer worked on previously, a couple things need to happen. First, the second developer needs to review and understand the work of the prior developer. Second, the second developer needs to insert new and revised code to support the new functionality.

When the second developer reviews the code, it is possible that she may have some ideas to make the code more efficient or easier to support. In a traditional project, there is a tendency to leave this inefficient code in place. The thought is that “if the code is not broken don’t fix it.” Therefore, prior code that seems to be working tends to be isolated so that new changes do not impact it. This approach usually results in code that becomes very “brittle” over time. “Brittle” means that developers don’t understand how the code works, and that errors are introduced whenever this old code is touched.

Agile projects take the opposite view. If a second developer has better ideas about the way a component is coded, the second developer takes the time to update the code. This constant review and modification of code is called “refactoring.” Refactoring is the continuous practice of updating prior code so that it is improved, better documented and optimized.

Refactoring may take more time to write and test during the current iteration. The greatest danger of touching old code is still that you will break something that works today. However, this risk is minimized on Agile projects by automated and rigorous testing so that any new errors can be quickly discovered and fixed. Any short-term impact is offset by continually delivering better and better code over the life of the project. The code will be cleaner, more efficient, more flexible, better documented and much easier to support longer term. The result is the ability of Agile teams to maintain more flexible and efficient solutions over the life of the product. 

The Challenges of Proving the Value of Project Management

/in /by

The Challenges of Proving the Value of Project Management
(part 2 of 2)

Last time, I described the challenges of trying to prove the value of project management. However, this does not mean we have to throw up our hands and give up. There are some ways to derive the value. 

Estimate benefits based on industry analysts

This is usually the place to start. Although you may have difficulty estimating the value of project management, other organizations have done detailed research. If you have nothing else, you can always take someone else’s word for it. There are reports from the Project Management Institute and some consultancy groups that show savings and project improvements associated with the use of project management. I have never seen a report that stated the use of project management practices was bad.  For example, if you find a report showing a 10% savings per project, you could apply this figure to your projects – assuming you are applying similar project management discipline.

Calculating detailed benefits per project management process

You can survey each project manager at the end of a project and ask questions about the specific value they observed, versus what would have happened if they did not use a specific process. This allows you to look at individual projects and project managers. Some project managers may think they managed projects well previously and do not see a lot of incremental value in a new common process. Other project managers may see tremendous value.

In this approach you look at all the specific benefits associated with standard project management and work with your project manager to place a value on them. Examples might be.

  • Savings in time and hassle associated with better managing client expectations.
  • Savings from scope change requests that are made but not approved. For example, the project manager may say that in old projects all scope change requests were included in project scope. Instead, using good scope change processes resulted in one-third of the requests being rejected. There are cost savings and accelerated schedules associated with not doing this work.
  • There is value associated with accurate estimating. As you do a better job planning and managing the work, you should find that your project estimates become more and more accurate. This allows the customer to better manage their financials and make better business decisions. You can agree with your customer on the value this better estimating provides to them.
  • If you managed risks well the project should have had fewer problems compared to the past. You can estimate the value of fewer problems on your schedule and budget.

You would need to define the detailed criteria that would be applied to each project. Then as each project completed, the project manager (and the sponsor) would sit
down and consider the value of the project management processes that were applied.

Consider the savings from projects cancelled

Planning projects more thoroughly and managing projects more closely may result in
some projects being cancelled that might have been executed before. This is the result of more information being available regarding the total cost of the project versus the
business benefit. If a project gets cancelled based on sound planning and management,
you should take credit for this as a win for the organization, and the budgeted money not
spent should go into the value side for project management.

The Challenges of Proving the Value of Project Management (part 1 of 2)

/in /by

 

The Challenges of Proving the Value of Project Management
(part 1 of 2)

There are a number of factors that make it difficult to quantify the value of project management to an organization.

You can’t precisely compare projects before and after

One of the characteristics of projects is that they are all unique. Therefore, you
cannot make a direct apples-to-apples comparison of what projects looked like before the use of project management processes and after the fact. What you would like to say is that it took us X hours to do a project before, and now it takes Y. However, two projects are never exactly the same to make this comparison.

You don’t have the baseline metrics

You may be able to make some general statements by comparing projects with similar characteristics. However, most companies don’t keep any historical records of project
characteristics and costs to use in this type of comparison. You can track the costs and durations of current projects, but how do you compare to the past when you weren’t capturing any information.

There is a lot of other stuff going on

A project management initiative in a large company requires a fair amount of time to be successful. In fact, it may take a few years in a large company before everyone is trained and using the new methodology. Of course, no organization can stand still while a long culture-change initiative is going on. The problem is that it is hard to tell how much impact the project management initiative has on the organization versus the other factors that are coming into play at the same time. 

Things may be a little worse before they get better

Lastly, the introduction of structured processes in an organization that did not have them
before might well result in some short-term incremental costs before the long-term value comes in. For instance, you may need to invest in training and perhaps some ongoing coaching. In addition, there will probably be a learning curve. If the project is long enough, the long-term savings could outweigh the learning curve. However, if the project is short, the participants may tell you that it took longer than it would have if the methodology were not in place. This is not surprising. The overall value of the project management processes must be measured over time, since much of the value will kick in through the reuse of the common processes.

Stay Tuned

All that being said, there are some ways to show the value of project management. Look for these ideas in the next email.

Use Milestones to Take a Checkpoint  and Validate Your Status

/in /by

Use Milestones to Take a Checkpoint
and Validate Your Status

A milestone is a scheduling event that signifies the completion of a major deliverable or a set of related deliverables. A milestone, by definition, has duration of zero and no effort. Milestones are great for managers and the sponsor because they provide an opportunity to validate the current state of the project and what the future looks like.If the milestone is important enough you could perform an end-of phase review. However, some milestones represent the completion of smaller deliverables or deliverable components and don’t rise to the level of holding a full end-of-phase review.

You can complete the following activities at every milestone:

  • Validate that work done up to this point is correct and accurate. The sponsor should have approved any external deliverables produced up to this point.
  • Make sure that the rest of the project schedule includes all the activities necessary to complete the project.
  • Double-check the effort, duration and cost estimates for the remaining work. Based on prior work completed to date, you may have a much better feel for whether the remaining estimates are accurate. If they are not, you will need to modify the schedule. If it appears that your budget or deadline will not be met, raise an issue or a risk and resolve the problems now.
  • Issue a formal status update and make any other communications specified in the Communication Management Plan.
  • Evaluate the Risk Register to ensure previously identified risks are being managed successfully. You should also perform another risk assessment to identify new risks.
  • Update all other project management logs and reports.
  • Make sure the project still makes business sense. If a project is long, the business case may change as the project progresses.
  • Make sure the sponsor is still engaged.
  • Make sure the resources need for the next phase are ready.

These activities should be done on a regular basis, but a milestone date is a good time to catch up, validate where you are, get clear on what’s next and get prepared to charge ahead.

Estimate Project Costs Across Three Main Categories

/in /by

Estimate Project Costs Across Three Main Categories

Once you understand the work of the project you can estimate the resources that will be required to complete the work. Knowing the resources allows you to estimate the costs of the resources to the project. There are three main areas where costs come into play.

Labor costs

The cost of labor is derived by looking at the effort hours of each resource and multiplying by the hourly (or daily) cost of each resource. In many companies, estimated labor costs for internal employees are assumed to be zero, since their costs are already accounted for in a departmental budget. This does not imply there is no cost. Rather, it assumes there are no incremental costs over and above what the company is already paying for.

If you are using external contract or consulting resources, their costs always need to be estimated and budgeted. You have to determine the type of external resources you need and the hourly rate of the resources and how many hours you need. If you are not sure of the actual resource cost, you need to make some assumptions based on the general type of resource. For instance, there may be a standard hourly cost for accounting contractors or programming contractors.

Non-labor costs

Non-labor expenses include all resource costs not directly related to salary and human contractor costs. Some of these costs, like training and team-building expenses, are related to people. However, they are still considered non-labor since they are not related to employee salary or contractor hours. Non-labor costs include:

  • Hardware and software
  • Travel expenses
  • Training 
  • Facilities
  • Equipment
  • Material and supplies
  • Depreciation
  • … more

Each project manager must be aware of the accounting rules in his own company to make sure the labor and non-labor costs are allocated correctly.

Outsourced costs

This is a third category of costs. For practical purposes this is considered non-labor costs. However, it is a cost that is provided to you by a vendor to complete some pre-specified piece of work. As a project manager, you don’t need to determine resources and the costs of resources. This is the vendor’s responsibility. You just need to understand the scope of work to be completed and the cost of that work. In some projects, especially construction and engineering, the vast majority of the work may be outsourced to vendors. On those projects it is important to provide clear scope of work feedback to the vendors and then aggregate that costs of all vendors to come up with final project cost estimates.  

Document all assumptions

Don’t forget. You will never have all the information you need with 100% certainty. Therefore, it is important to document all the assumptions you are making along with the estimate. If you change your assumptions, it is likely to change your estimates.

Four Planning Techniques to Save Time on Your Project

/in /by

Four Planning Techniques to Save Time on Your Project

“Planning” is a very general term. When you say you are planning a project, you are really validating scope, creating a Charter, estimating, creating a schedule, and more. Here are four techniques to use when you plan your projects. They may take a little longer in the planning process, but will save you much more time over the life of the project.Use Multiple Estimating Techniques if Possible

An important part of planning is being able to accurately estimate the work activities. Estimates of effort hours will, in turn, drive the cost and duration estimates. There are a number of techniques that can be used to estimate work – analogy, expert opinion, PERT, modeling and more. If possible, try to use two or more techniques for the estimate. If the estimates from multiple techniques are close, you will have more confidence in your numbers. If the estimates are far apart, you can look at the reasons and determine whether one technique may be more accurate than another.

Plan at Least One-Phase Ahead

Doesn’t it seem that most problems that are encountered on a project tend to surface later rather than earlier? In fact, some project managers purposely hurry through planning because they think they will catch any mistakes and fix them as the project progresses. 

Unfortunately, the longer it takes for errors to be caught, the more time-consuming and expensive it is to fix them. Try to prepare for each phase of the project at least one phase in advance. For instance, fully planning the work will save time in the analysis phase. Getting the analysis work right the first time will make the design phase go more smoothly. In general, smart time investments early will more than make up for itself in future phases.

Create a Short-Term Schedule to Guide the Planning Processes

The process of planning the work may take a long time and may be very complicated. Therefore, the work should not be unorganized – for the same reasons that you are building the schedule for the project to begin with. Immediately after being assigned, the project manager should create a short-term schedule to cover the initial planning activities. For example, if the planning work is expected to take four weeks, you need a preliminary schedule that covers at least four, if not five or six weeks. This preliminary schedule covers all of the organizing and up-front planning activities until the formal project schedule is completed to guide the remainder of the project.

Establish the Triple Constraint when the Planning is Completed

At the end of the planning process you should have an agreement with your sponsor on the scope of work, the cost and duration that are needed to complete the work. These three items form a concept called the “triple constraint”. The key aspect of the triple constraint is that if one of the three items change, at least one, if not both, of the other items need to change as well. For example, if the scope changes, normally budget and schedule change as well. If the timeline is reduced, it may require a decrease in scope and/or an increase in cost.

Gain More Performance Feedback with a 360 Degree Review

/in /by

Gain More Performance Feedback with a 360 Degree Review

Performance reviews can be a stressful time for staff – and managers. It takes a great deal of thought and care to give honest and thorough performance feedback

. If you have to deal with negative performance, the anxiety level can be off the scale. Because performance feedback is difficult, many, if not most, performance reviews are shallow at best.

One of the major criticisms of the review process is that managers cannot see how a person performs on the job – especially if the employee works on projects with different project managers.

A 360 degree review provides more realistic perceptions of performance

One way to be as fair as possible with employees is to ensure that performance feedback is not totally based on the manager’s perception. The manager should also seek feedback from other people that the employee works with on a daily basis. This is called a 360 degree review process. Typically this includes feedback from the rest of their team (peers) and relevant stakeholders. If the employee is also a manager (functional manager or project manager), feedback is also sought from their direct reports.

The main purpose is to help the reviewee

The 360 degree feedback is a way to help the manager get a more balanced view of the employee’s performance. However, the ultimate value of this process is realized by the person being reviewed. The employee should see the review process as an opportunity to get an outside perception of his strengths and areas where he can improve. Ultimately the employee should take a personal interest in the review process to ensure that he can grow professionally and provide more and more value to the organization.

The 360 degree review process provides more input to the employee. Not only do you have performance input from your manager, but you have feedback from stakeholders, team members, and direct reports as well. This feedback is invaluable to see how others view you, your skill level and your performance level.

Review Three Techniques to Create a Work Breakdown Structure

/in /by

Review Three Techniques to Create a Work Breakdown Structure

The Work Breakdown Structure (WBS) is the first step to create a schedule. The WBS helps break the project work into smaller pieces that help more easily understand the work. Here are three techniques that can help you understand the WBS for your project.

1. Understand the difference between detail and summary activities

If you look at a WBS activity and determine that it needs to be broken down to another level, the original activity becomes known as a “summary” level. A summary activity represents a logical roll-up of the activities that are under it. On the other hand “detailed” activities are those that have not been broken down further. Once the detailed activities are under the summary activity are completed, the summary activity is also considered to be completed.

2. The top-level of the WBS can be the hardest to define

Sometimes people have a hard time getting a WBS started because they are not sure what to put at the very top and they are uncertain about how to break the work down from there. There are a number of options for defining the WBS at level 1 (under the top level 0).

  • It might make sense to place the major project deliverables directly at level 1, and break the deliverables into smaller components on the next level, if necessary.
  • Another option for level 1 is to describe the organizations that will be involved, such as Sales, Marketing, IT, etc. The next level should describe the deliverables that each organization will produce. 
  • A third option is to look at level 1 in terms of the project life cycle; for instance analysis, design, construct, etc. If that is the best logical way to look at level 1, then level 2 should describe the deliverables produced in each life cycle stage.

Although there are many ways that the WBS can be started, ultimately you want to uncover deliverables.

2. Identify top-level structure first, then deliverables, and then activities

After the top level (or maybe level 2), you start by writing the names of the major deliverables on Post-it notes – one deliverable per note. The deliverables are placed within the organization structure defined at level 1 – by organization, by phase, etc. If any of the deliverables are very large, you can create a lower level under that deliverable that describe the deliverable at a lower level. This lower level is a “work package”. In general two levels should be enough to describe the deliverables and the work packages that make up the deliverable. A very complex deliverable might need three levels.

At this point you have a deliverable-based WBS. You can break the work down further into the detailed activities that are needed to actually build the deliverables. If you go to this kevel you have an activity-based WBS.